For GPU builds, the host compiler should get these compile flags as well.
PiperOrigin-RevId: 351470659
Change-Id: I8610ac871e370895f9234e3f047e7ee90557db86
Should resolve issue reported in #45744, #45866, #44701 and #45991 as well as multiple other issues from other ecosystem places.
We will patch 2.4 soon and release proper patches.
PiperOrigin-RevId: 350243794
Change-Id: I0aa814dedb44ac3ec992a0a432f117122337023f
Bug fixed: https://github.com/bazelbuild/bazel/issues/3828
We need this because we are working on integrating TF with a different project that should remove the breakages caused by LLVM integration
PiperOrigin-RevId: 348886284
Change-Id: Iad539321f1ba7590e4ee77b93d67eb5401d9fec8
When we switched to ROCm 3.3 (first ROCm release with "relocatable ROCm install" support), some parts of the ROCm toolchain relied upon the value of env var ROCM_ROOT to determine the location of the ROCm install dir. This has been fixed, and all of the ROCM toolchain now only uses the ROCM_PATH value.
This commit updates `configure.py` to no longer set ROCM_ROOT, when building with --config=rocm
Related JIRA ticket - http://ontrack-internal.amd.com/browse/SWDEV-226744
This flag was first made available in Visual Studio 16.4, (as of 2020-11-11,
VS is at version 16.8), and can now be considered generally available.
See also #38254
PiperOrigin-RevId: 342158585
Change-Id: Ice96be9a1392313357b314407262a005a2436a4d
This PR removes now-deprecated direct integration of nGraph in TF. nGraph
integration is still available via the external ngraph-bridge at:
https://github.com/tensorflow/ngraph-bridge/
or via `pip install ngraph-tensorflow-bridge`.
Signed-off-by: Abhishek Kulkarni <abhishek.kulkarni@intel.com>
Adds build option and supporting macros for oneDNN-reference builds on Aarch64.
For now, oneDNN will link to GCC's libgomp.so. See, related issue: https://github.com/tensorflow/tensorflow/issues/42858
Signed-off-by: cfRod <crefeda.rodrigues@arm.com>
MLIR generated gpu kernels will continue to be disabled by default.
This commit provides a way to enable them, if conifugre.py is run with the env `TF_ENABLE_MLIR_GENERATED_GPU_KERNELS=1`
Currently, if the version check fails, the error message is:
```
subprocess.CalledProcessError: Command '['bazel', '--batch', '--bazelrc=/dev/null', 'version']' returned non-zero exit status 1.
```
After this patch, it becomes:
```
Error checking bazel version: ERROR: The project you're trying to build requires Bazel 3.0.0 (specified in /usr/local/google/home/cheshire/code/opensource/docker_tf/tensorflow/.bazelversion), but it wasn't found in /usr/bin.
You can install the required Bazel version via apt:
sudo apt update && sudo apt install bazel-3.0.0
```
PiperOrigin-RevId: 312520687
Change-Id: I41523f7defa3db10aa34b6b313d6b65c792b2020
Avoid using `--enable_platform_specific_config` when cross-compiling for
iOS/Android, as this pulls in host build flags, which may not be
appropriate (e.g., when cross-compiling for Android on a Windows host).
Also fix an issue when building tensorflowlite_c for iOS.
Fixes#38525.
PiperOrigin-RevId: 311767770
Change-Id: I80b817fd89a6889dc78be50f1def8b899f091cb6
Use `bazel --version` instead of `bazel --batch version`.
`bazel --batch` fails on Windows with a "command line too long" error, if user's environment variable is too large.
Example: https://buildkite.com/bazel/bazelisk-plus-incompatible-flags/builds/496#f5fbd8db-7421-43f4-a018-555af9856be4
`bazel --version` can also print the Bazel version without starting Bazel server, it's even faster than `bazel --batch version`.
PiperOrigin-RevId: 310570885
Change-Id: Iafc4c90f0ff57610e5f77bee230e81e78d9f1289
Environment variables are strings, not integers.'0' does not evaluate to false.
PiperOrigin-RevId: 297916971
Change-Id: I9df143690b16a181fa5f0c4a60ac2f944b396672
Remove the prompt for XLA in configure. But still allow users to build without it for platforms like raspberry pi.
PiperOrigin-RevId: 297713015
Change-Id: I7a12b073389c1cf3d265e00952f28e98470c80ff
This is necessary to start using bazel's experimental cc_shared_library support.
This change is part of the refactoring described in https://github.com/tensorflow/community/pull/179
PiperOrigin-RevId: 294736824
Change-Id: I8d13c71545cf2f2edd47818b40fa413e3e9c3254
Today if you run the ./configure script without setting the
variable TF_NEED_CUDA, in the resulting .tf_configure.bazelrc
you get:
test:v1 --test_tag_filters=-benchmark-test,-no_oss,-gpu,-oss_serial
test:v1 --build_tag_filters=-benchmark-test,-no_oss,-gpu
test:v2 --test_tag_filters=-benchmark-test,-no_oss,-gpu,-oss_serial,-v1only
test:v2 --build_tag_filters=-benchmark-test,-no_oss,-gpu,-v1only
This is incorrect because -gpu means exclude the gpu test. It should be
-no_gpu.
Debugging the problem I found when the code was switched from using
os.env to using environ_cp, that the method system_specific_test_config
was never updated. So unless the environment variable TF_NEED_CUDA was
set before running ./configure then answering yes for CUDA would not
select the correct test filter for gpus.
With this change the test filters are correct:
test:v1 --test_tag_filters=-benchmark-test,-no_oss,-no_gpu,-oss_serial
test:v1 --build_tag_filters=-benchmark-test,-no_oss,-no_gpu
test:v2 --test_tag_filters=-benchmark-test,-no_oss,-no_gpu,-oss_serial,-v1only
test:v2 --build_tag_filters=-benchmark-test,-no_oss,-no_gpu,-v1only
This is necessary to start using bazel's experimental cc_shared_library support.
This change is part of the refactoring described in https://github.com/tensorflow/community/pull/179
PiperOrigin-RevId: 288808507
Change-Id: Ie78fb4ff8dad128ebef280037cce4d3c4f42addc
1. Rewrote hipcc_cc_toolchain_config.bzl.tpl.oss based on third_party/bazel/tools/cpp/unix_cc_toolchain_config.bzl
2. Cleaned up non-Linux stuff in toolchain configuration
3. Added support for parameter file in the compiler wrapper script
4. Re-generated preconfigured toolchain by third_party/tensorflow/third_party/toolchains/preconfig/generate/update.sh ubuntu16.04-py3_opt-gcc5-rocm
5. Bumped min Bazel version to 0.27.1 because toolchain configure requires newer Bazel
6. Removed --noincompatible_do_not_split_linking_cmdline
PiperOrigin-RevId: 278844463
Change-Id: I477ec5b44e6c634db7c6d65d02b3e307f0be338b
This may be valuable to enable globally (and disable via a user flag), but for now I've enabled it for one specific call which was causing an error in #32776.
Resolves#32776.
PiperOrigin-RevId: 276094797
Change-Id: I6f007a50311c00885cf0db2d291f4d00294d53d7
Besides upgrading the Bazel version, we also refactored all build scripts to use rbe options in .bazelrc file.
In order to migrate for https://github.com/bazelbuild/bazel/issues/7480, we have to specify the complete strategies list in .bazelrc file.
PiperOrigin-RevId: 275459466
Change-Id: Iaec997da7862245955a36ebb1018d901f61c591d
We always use RTLD_LOCAL for dynamic linking TensorRT in open source so the
symbol conflicts should not affect OSS builds.
PiperOrigin-RevId: 268983417
The blacklist was working around an ODR violation problem that is triggered by
linking in TensorRT and cuDNN into the same binary.
In open source TensorRT is off by default and this CL adds an admonition about
the possible problem.
PiperOrigin-RevId: 268942282
This check was added because libopenblas on Power had threading
issues if OMP_NUM_THREADS was set higher than 1. This has been
fixed in all the latest versions of libopenblas and this check
is no longer needed.
HDFS is now supported through bazel build config and not through a flag in this file (`configure.py`).
However, the docstrings still refer to it. Replaced it with `TF_NEED_CUDA`, which is still a flag set in this script
Use a single python script (third_party/gpus/find_cuda_config.py) from configure.py and the different *_configure.bzl scripts to find the different CUDA library and header paths based on a set of environment variables.
PiperOrigin-RevId: 243669844
Allow setting the level via $ANDROID_NDK_API_LEVEL, rather than
hardcoding to the current NDK version. Also increase the default
NDK API level to 18.
PiperOrigin-RevId: 241981236
Right now, "0.24" is treated as lower than "*.*.*" because of the odd comparison method that adds digits to each existing section. This change converts "0.24" to "0.24.0" to fix that.
This will probably need to be pulled into r2.0.
PiperOrigin-RevId: 241950768
Imported from GitHub PR #26752
This makes builds not fail with --incompatible_remove_old_python_version_api enabled, which will become the default in Bazel 0.25. Fixes#26616.
Copybara import of the project:
- a3b9e5cde69beb5b1ceebe9a4a20c352bf320290 Bump abseil-py dep and min Bazel version by Jon Brandvein <brandjon@google.com>
- d189be43b2bf4bcd229d4fe23bc95870a196ff79 Merge a3b9e5cde69beb5b1ceebe9a4a20c352bf320290 into 9ab5b... by Jon Brandvein <brandjon@google.com>
PiperOrigin-RevId: 240409003
ERROR: cc_toolchain_suite '@local_config_cuda//crosstool:toolchain' does not contain a toolchain for CPU 'k8', you may want to add an entry for 'local|compiler' into toolchains and toolchain_identifier 'local_linux' into the corresponding cc_toolchain rule (see --incompatible_disable_cc_toolchain_label_from_crosstool_proto).
PiperOrigin-RevId: 225430355
Bazel-0.18.0 adds a try-import option that will non-fatally try and
import a file. Use this for the configure options so that .bazelrc does
not need to change. ./configure rewriting .bazelrc makes using the git
repo annoying because the file is changed.
The allowed bazel range is now 0.18.0-0.20.0 inclusive. The env var
TF_IGNORE_MAX_BAZEL_VERSION can be set to skip the max bazel version
check.
Also optionally import a /.bazelrc.user file that is gitignored so
user-specific options can go in there.
Fixes: https://github.com/tensorflow/tensorflow/issues/22762
Fixes: https://github.com/tensorflow/tensorflow/pull/22906
Signed-off-by: Jason Zaman <jason@perfinion.com>
After a few fixes, TensorFlow now builds with Bazel 0.20.0. This allows us to keep testing TF on Bazel CI, where bazel is already upgraded to 0.20.0
PiperOrigin-RevId: 224006905
When the user choosen python_lib_path was retreived from the
PYTHONPATH environment variable, need to set PYTHONPATH in the
bazelrc file so bazel includes it in all the build operations.
Fixes tensorflow#23695
