Building TensorFlow with custom GCC requires hardcoded ld,nm and as #1713
Comments
|
Hi @akors, this is pretty strange, but we can figure out together what's going on here. :) Could you please provide the following:
Thanks! |
Here is the env output. Note that
The output is indeed quite long because it is cluttered with compiler warnings. I have pasted only the last few messages.
Oops, my bad, they are actually in By the way, this is version 0.3.0 from the Ubuntu repositories: If I compile bazel from the current HEAD, I get this weirdness: |
Just to be sure, did you check that this not not related to the way you Thanks, Klaus Aehlig |
Yes, it works perfectly fine: |
Can you please provide the (tail of the) output of "bazel build -s //your:target"? Note the "-s" Options Thanks, Klaus Aehlig |
|
@aehlig The full log can be accessed here: |
|
Any update on this? I have the same problem with my local gcc |
|
There are two aspects to that issue. (a) Passing through environemt variables; this should be solved (b) There is the "autoconfiguration" aspect, where bazel tries to be smart and infer properties Klaus Aehlig |
|
@aehlig: I'm not :) I kind of agree with the sentiment that the autodetection should work better, but the smarter it is, the more surprising it is when it doesn't work, so a bit of care needs to be taken. What do (Note, though, that that command can return non-normalized paths e.g. with |
To make matters unnecessarily complicated, in the case of tensorflow, there are 2 compilers involved: the one that builds the CUDA kernels (used by nvcc), and the one that builds the rest. Those can be separate compilers, if I understand correctly. Not asking for the ultimate solution here, this is just a heads-up.
I gotta say, getting "no such file or directory" errors for binaries that very much exist and are on the PATH, which doesn't happen when running directly without bazel is somewhat surprising to users as well ;)
Just tried it out, and that depends on if the values were hardcoded during compiler compilation or not: Here, the first one is with hardcoded paths (configured with |
|
Yeah... unfortunately, passing http://www.bazel.io/docs/designs/2016/06/21/environment.html It's essentially a balancing act between actions being reproducible (and thus not dependent on the environment Bazel is run in) and convenience. |
Hi! I am using Fedora 23 and Ubuntu 16.04.1 LTS to build TensorFlow with GPU support.
GPU support requires a specific GCC version, 5.3 for successful compilation. Since this version is not available from the Fedora Package repositories, it has to be compiled from source. Unfortunately, there are a few obstacles using this version with bazel.
One of those is the following:
After configuring TensorFlow with the self-compiled GCC, and running bazel, the compilation stops with the following message:
gcc: error trying to exec 'as': execvp: No such file or directoryor
gcc: error trying to exec 'nm': execvp: No such file or directoryor
gcc: error trying to exec 'ld': execvp: No such file or directoryTo work around this, one can compile GCC by hardcoding the paths to those tools, by adding this to the configuration line of GCC:
--with-ld=/bin/ld --with-nm=/bin/nm --with-as=/usr/bin/asThis does seem rather strange, however, because those programs are on the path, and the custom GCC without bazel is capable of producing working binaries just fine. I feel that in a well-working build system, this kind of hacks should not be necessary.
There was a TensorFlow issue for this: tensorflow/tensorflow#2806 but the devs believe that this is a bazel problem.
The text was updated successfully, but these errors were encountered: