I try to build tensorflow-serving using bazel but I've encountered some errors during the building
ERROR:/private/var/tmp/_bazel_Kakadu/3f0c35881c95d2c43f04614911c03a57/external/local_config_cc/BUILD:49:5: in apple_cc_toolchain rule #local_config_cc//:cc-compiler-darwin_x86_64: Xcode version must be specified to use an Apple CROSSTOOL.
ERROR: Analysis of target '//tensorflow_serving/sources/storage_path:file_system_storage_path_source_proto' failed; build aborted.
I've already tried to use bazel clean and bazel clean --expunge but it didn't help and still Bazel doesn't see my xcode (I suppose) but it's completely installed. I even reinstalled it to make sure that all works fine but the error didn't disappeared
My Bazel version is
Build label: 0.5.2-homebrew
Build target: bazel-out/darwin_x86_64-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Thu Jul 13 12:29:40 2017 (1499948980)
Build timestamp: 1499948980
Build timestamp as int: 1499948980
KakaduDevs-Mac-mini:serving Kakadu$
OS is MacOS Sierra version 10.12.5
What should I do to specify Xcode version in bazel to avoid this error? It seems that the error is common but I haven't found how I can make the bazel build.
P.S I'm trying to install tensorflow-serving the way it's explained here.
https://tensorflow.github.io/serving/setup
bazel clean --expunge
sudo xcode-select -s /Applications/Xcode.app/Contents/Developer
sudo xcodebuild -license
bazel clean --expunge
bazel build --config=opt //tensorflow/tools/pip_package:build_pip_package
Had the same problem, and since I am using a beta version of XCode, I had to find the installation in /Downloads/Xcode-beta.app instead.
Incidentally, the solution for me was to open XCode, go to Preferences, and select the Locations tab. The Command Line Tools drop-down was blank, and I had to press it and select a version (Xcode 9.0 in my case). I then ran bazel clean --expunge and repeated the build process without getting the error. Hope this helps someone.
It looks like xcode_configure isn't properly identifying that you have xcode installed. This can sometimes happen if you install xcode but have not yet fully opened it (it may ask you to agree to Terms and Conditions before being fully functional). If this is the problem, you'll need to bazel clean --expunge again after that...
If this doesn't help, you can get some debug information to identify what's gone wrong, by invoking (after a failed build):
cat $(bazel info output_base)/external/local_config_xcode/BUILD
This should contain some comments pertaining to failures in finding your installed xcodes.
For me it was a licensing issue for xcodebuild. After running
bazel clean --expunge
I've tried to run again bazel and I've got the instruction to run
sudo xcodebuild -license.
I have executed, accepted the license terms, run again
bazel clean --expunge
and everything has started to work again.
Hopefully it solves some of the cases.
In order to build objc, Bazel requires that you specify an xcode version - this is usually done automatically by xcode_configure. If that's not working, you can manually specify the xcode version on the command line using the --xcode_version flag.
Related
newbie here, first message :)
I need tensorflow with CUDA, AVX and SSE on a windows machine. As far as I understood I need to build it myself. I first tried with Anaconda, but it was a mess, so I uninstalled anything related to python and I started following step by step the official guide
I used several commands to build, for instance:
bazel build -c opt --copt=-march=native --copt=-mfpmath=both --config=cuda -k //tensorflow/tools/pip_package:build_pip_package
bazel build -c opt --copt=-mavx --copt=-mavx2 --copt=-mfma --copt=-mfpmath=both --copt=-msse4.2 --config=cuda -k //tensorflow/tools/pip_package:build_pip_package
bazel build --config=opt --config=cuda --define=no_tensorflow_py_deps=true //tensorflow/tools/pip_package:build_pip_package
The first two commands came from here and might be old.
The building always fails with this message:
ERROR: missing input file 'external/llvm-project/mlir/include/mlir/Interfaces/SideEffectInterfaces.h', owner: '#llvm-project//mlir:include/mlir/Interfaces/SideEffectInterfaces.h'
Does anybody understand what is going on here?
Also, what is the best command to build among the one I used?
Is there any way to install it in Anaconda on windows (with CUDA, avx and SSE capabilities)?
Building tensorflow on windows can be tough, there are many ways for it to fail. The procedure will vary with the version you are compiling. For the most part, the instructions on the tensorflow site are correct if followed verbatim. I think the trickiest part is matching the version of tools used to compile with version of tensorflow you are working with.
My suggestion would be to lock into a particular version of tensorflow and stick with that until you succeed. If you git clone the source from github, I would suggest git checkout r2.2. This will put you into the most recent version.
I would avoid anaconda as that presents complications with the python version you are working with. I have had good results with python 3.6.8., but it may be possible to use 3.7.
You will need a specific version of Bazel as well, 2.0.0 is what works with tensorflow r2.2. Be mindful that you need to configure the BAZEL_VC environment variable before you start compiling. It should look something like C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC. You can do a bazel clean --expunge after the variable is set to avoid some confusion.
The r2.2 tensorflow also requires MSVC 2019, it will not compile with other versions. You will need the build tools for this version as well.
The last bazel build command you showed is the correct one. Don't forget to python ./configure.py before starting a fresh compile.
If my guess is correct, the error message you are getting is from using an older version of MSVC on the later tensorflow source code, but that's just a guess.
I have just installed gst-browser (VisualGST) through the Canonical Ubuntu repositories, so I tried to start VisualGST by running gst-browser on the command line. However, I am immediately greeted with an error:
a Smalltalk Stream:2: Abandon
a Smalltalk Stream:2: Error occurred while not in byte code interpreter!!
/usr/lib/libgst.so.7(+0x74c97)[0x7fb5fa5d1c97]
/lib/x86_64-linux-gnu/libc.so.6(+0x3ef20)[0x7fb5fa1aaf20]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0xc7)[0x7fb5fa1aae97]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x141)[0x7fb5fa1ac801]
/usr/lib/libgst.so.7(+0x2c6a6)[0x7fb5fa5896a6]
/usr/lib/x86_64-linux-gnu/libsigsegv.so.2(+0xe3c)[0x7fb5f9f68e3c]
/lib/x86_64-linux-gnu/libc.so.6(+0x3ef20)[0x7fb5fa1aaf20]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_type_check_is_value_type+0x23)[0x7fb5d4e374f3]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(+0x20785e)[0x7fb5d551185e]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(gtk_list_store_new+0xa4)[0x7fb5d5436d94]
[1] 14556 abort (core dumped) gst-browser
What is the cause and meaning of the error, and how can I start VisualGST properly?
GNU Smalltalk version: 3.2.5
EDIT:
This appears to be a known issue. There's a bug report from 2012 on Launchpad: Smalltalk browser does not launch.
This appears to to be "known" issue. As I previously guessed the issue was in libraries link(age).
You can solve your issue either by installing - libgtk2.0-dev.
You can find the whole conversation here. Here is an excerpt:
Digging a bit further, I found that the module "gst-gtk-3.2.92.so" is
linked against "libgtk-x11-2.0.so", which is (now?) only provided by
package: gtk2-devel.
Your second option is to compile it from source. On Fedora 27 (again from the discussion and link above):
I'm on Fedora 27 and after a fresh install this gave me a working build:
sudo dnf install gcc git automake bison flex libtool libtool-ltdl-devel libffi-devel libsigsegv-devel cairo-devel gtk2-devel texinfo
git clone git://git.sv.gnu.org/smalltalk.git
cd smalltalk
autoreconf -vi ./configure make
sudo make install
-----------------------
For future referece you can find testing gst-browser gist.
ERROR: /home/kenny/Downloads/tensorflow-1.5.0-rc1/tensorflow/contrib/lite/toco/BUILD:326:1: Linking of rule '//tensorflow/contrib/lite/toco:toco' failed (Exit 1)
/usr/bin/ld: warning: libcublas.so.9.1, needed by bazel-out/k8-py3-opt/bin/_solib_local/_U_S_Stensorflow_Scontrib_Slite_Stoco_Ctoco___Utensorflow/libtensorflow_framework.so, not found (try using -rpath or -rpath-link)
Check this issue comment
https://github.com/tensorflow/tensorflow/issues/15656#issuecomment-362104182
The current version of TensorFlow (1.7) does not support CUDA9.1, but you should have several options:
Downgrade to CUDA 9.0
Compile TensorFlow from the source code by your own
Find an existing whl file for you (unofficial release). ex. I fixed the issue by using a whl from https://github.com/mind/wheels
Wait until Tensorflow supports CUDA9.1 :)
Looks like you need to install Cuda 9.1 from Nvidia as a prerequisite to building from source.
I also had similar issue. Probably adding this flag --action_env="LD_LIBRARY_PATH=${LD_LIBRARY_PATH}" in your bazel build command will solve the issue. Make sure you have set the environment variable LD_LIBRARY_PATH as /usr/local/cuda/lib64 or wherever your cuda toolkit installation is present.
EDIT: In case setting up environment variable doesn't work. You can further try by running sudo ldconfig -v|grep 'libcublas.so.9.1'. In my case cuda's version is 9.1 hence I verify for the same. If grep doesn't return the expected library, just try other ways to register your path to ldconfig
It's a weird dynamic link lib error.
Somehow bazel doesn't recognize LD_CONFIG. You'll have to manually update the /etc/ld.so.conf (in my case with Ubuntu 17.1, the config files are in /etc/ld.so.conf.d), and add a line that points to the /usr/local/cuda/lib64 folder.
Then run
sudo ldconfig
to re-build the ld cache. You can verify that the cuda libs are in the search folders by
sudo ldconfig -v | grep cuda
The build should work now.
I've been trying to install tensorflow with GPU support using these steps:
http://www.nvidia.com/object/gpu-accelerated-applications-tensorflow-installation.html
and also using:
http://thelazylog.com/install-tensorflow-with-gpu-support-on-sandbox-redhat/
This is the error message that I'm getting when I try to run the bazel build command for building the tensorflow pip package (with the --config-cuda flag set):
The specified --crosstool_top '//third_party/gpus/crosstool:crosstool' is not a valid cc_toolchain_suite rule.
What's strange is that if i remove the --config=cuda flag, I don't get the error message while building and I'm able to install tensorflow successfully - but without GPU support.
I experienced the same issue, using the nvidia instructions. What I did was to drop the git reset line in the instructions, and it works.
Details (from the error message):
Close, reopen terminal
Run git clone (again), and cd tensorflow
Run ./configure
Bazel build, etc
This may be unrelated, but I experienced an issue with the .whl line, the error message was that the wheel cannot be found or something along those lines. This is the "And finally install the TensorFlow pip package" section. To resolve it in my case, I typed in the terminal all the way to "..._pkg/tensorflow", and then pressed tab for auto-completion. The file name that popped up was significantly longer than that in the guide, but it worked. Also, if anyone face a numpy not installed message based on the nvidia instructions, replace the python-pip and dev with python-numpy and run that line again to install.
Configuration: Fresh Ubuntu 16.04, GTX970M, running driver 367.48 (from CUDA installation), CUDA 8.0, CuDNN 5.1
Full setup path:
Fresh Ubuntu, with downloads and 3rd party apps selected during installation.
Control panel => Software and updates => Other Software => Canonical ticked
Install CUDA using nvidia instructions in CUDA documentation, .deb format
CuDNN 5.1 installed, the rest from the nvidia link.
I hope everything works out for you!
(I'm sorry for the poor formatting)
I was going through same problem and recently found the solution. The problem is with the installation of Bazel which leads to this kind of error.
After installation of bazel from installer, make sure that you would give the correct path to ~./bashrc and also activate the path using
source "path-to-your-bin-directory-for-bazel"
Please change the git source version slightly as shown below
$ git clone https://github.com/tensorflow/tensorflow
$ cd tensorflow
// $ git reset --hard 70de76e
$ git reset --hard 287db3a
And please refer the below l
https://github.com/tensorflow/tensorflow/issues/4944
Also, zlib has been updated since this TF build. You need to check http://www.zlib.net/ to get the latest version and SHA-256, then update tensorflow/workspace.bzl with that information (lines 254-266 in this build). At this time, the correct version info would include the following:
url = "http://zlib.net/zlib-1.2.11.tar.gz",
sha256 = "c3e5e9fdd5004dcb542feda5ee4f0ff0744628baf8ed2dd5d66f8ca1197cb1a1",
strip_prefix = "zlib-1.2.11",
I'm running Elementary OS, which is based on Ubuntu 14.04LTS. Ninja is at version 1.3.4. When running Meson, I get the error:
ninja: fatal: ninja version (1.3.4) incompatible with build file ninja_required_version version (1.5.1).
According to http://www.mariocampos.io/blog/meson,-first-impressions/ I can fix this by getting a newer version of Ninja. That's fine, I can do that. However, I prefer to keep to the software in the package repos, so my question is:
Can I tell Meson to generate a Ninja build file that doesn't require such a high version, or does Meson use Ninja features only available in 1.5.1?
Indeed, as you can see in meson git repository, ninja minimum version was raised from 1.3.4 to 1.5.1 on December 3 2014 for the following reason:
To celebrate the new version of Ninja in Debian, start using the console pool.
One solution would be to use an older meson-build version (basically MAXIMUM version 0.21.0).
Can I tell Meson to generate a Ninja build file that doesn't require such a high version
No. It's hard coded in the meson source code.
does Meson use Ninja features only available in 1.5.1?
Yes. It's the Console Pool.