Bazel: How to troubleshoot this: ERROR: infinite symlink expansion detected

[yurivict]

I'm getting the tensorflow build failure: https://github.com/tensorflow/tensorflow/issues/21366

How can I find what link is bazel talking about? Could you please include it in the error message?

[ittaiz]

+1
We have a similar issue (of expansion) from a repository rule that’s
misbehaving and it’s hard to debug
On Sat, 4 Aug 2018 at 2:14 yuri@FreeBSD [e-mail] wrote:

I'm getting the tensorflow build failure: tensorflow/tensorflow#21366
https://github.com/tensorflow/tensorflow/issues/21366

How can I find which link is bazel talking about? Could you please include
it in the error message?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/bazelbuild/bazel/issues/5763, or mute the thread
https://github.com/notifications/unsubscribe-auth/ABUIFxCnpLKNnul92Q7lZDUZMW-REZ2iks5uNNlfgaJpZM4VuuQZ
.

[yurivict]

By tracing system calls I found that this link caused the problem:

/usr/ports/science/py-tensorflow/work-py27/tensorflow-1.10.0-rc1/bazel_ot/2cc1156aa366d993caf19cae8ee5ba0d/external/org_tensorflow
->
/usr/ports/science/py-tensorflow/work-py27/tensorflow-1.10.0-rc1

It isn't necessarily an error to have such link, even though it is cyclic. bazel should only fail when it actually becomes a problem, ex. system call fails (ELOOP/EMLINK/etc).

The tensorflow build itself creates this link. Somebody from bazel or tensorflow team, please advise.

[yurivict]

Do google projects like bazel have management?

Why does google promote bazel and projects based on it and then doesn't fix bugs in them like this one?

[ittaiz]

This is an open source project.
You can contribute to it.
The fact that google leads it doesn’t mean they will do everything.
On Thu, 23 Aug 2018 at 5:37 yuri@FreeBSD [e-mail] wrote:

Do google projects like bazel have management?

Why does google promote bazel and projects based on it and then doesn't
fix bugs in them like this one?

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
https://github.com/bazelbuild/bazel/issues/5763#issuecomment-415263286,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABUIF1Qe8H5K_okAQWCF7hV7_qRYHbflks5uThWEgaJpZM4VuuQZ
.

[yurivict]

I don't see the point of bazel. Why is it needed? Is cmake/meson not enough? cmake and meson work fine for thousands of other projects. bazel is an internal google tool. Why would anybody else be interested in helping google fix bugs in their internal tools ...

[dslomov]

Looks like tf's build issue.

[robinp]

(Cross-posting from tf issue, with more details here)

FYI I saw a remedy in https://github.com/NixOS/nixpkgs/blob/57004738b168663bb4053c6737053e0039cc6259/pkgs/development/tools/build-managers/bazel/python-bin-path-test.nix which is to use bazel --output_base=/something/other/path.

The issue seems to be when $HOME is pointed inside the workspace. Bazel creates a symlink mirror of the WORKSPACE (at least its top) in a cache dir inside its output_base, which defaults to like inside $HOME... which leads to recursive symlinks.

I wonder why is this cycle not a warning, that is just not traversed subsequently.

So a remedy is to define output_base to be outside home. Alternatively, try not to point $HOME inside the workspace (rather push the workspace dir into a $HOME subdir).