New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bazel HEAD breaks rules_go on macOS #4659

Closed
buchgr opened this Issue Feb 19, 2018 · 8 comments

Comments

Projects
None yet
5 participants
@buchgr
Contributor

buchgr commented Feb 19, 2018

The below tests fail with Bazel from HEAD on macOS but work bazel 0.10.1. The corresponding test.log files can be found behind the links.

//tests/legacy/cgo_library_root_dir:cgo_library_root_dir

//tests/legacy/gc_opts_unsafe:check_unsafe_cgo_client_lib

//tests/legacy/gc_opts_unsafe:check_unsafe_cgo_lib

Any guidance would be great @jayconrod @jmmv maybe?

@jayconrod

This comment has been minimized.

Collaborator

jayconrod commented Feb 20, 2018

@buchgr I'm getting access denied errors from all the links. Can you make them public?

@jayconrod

This comment has been minimized.

Collaborator

jayconrod commented Feb 20, 2018

I built from source and tried to run the rules_go tests. Output is below. This was on a Debian / Rodete workstation.

Is Jenkins not running tests for rules_* repositories anymore after Bazel changes?

rules_go $ /usr/local/google/home/jayconrod/Code/bazel/bazel-bin/src/bazel test //...
Extracting Bazel installation...
...
Server crashed during startup. Now printing '/usr/local/google/home/jayconrod/.cache/bazel/_bazel_jayconrod/7e5a5a4544b57e311691c3a03ea8d383/server/jvm.out':
JNI initialization failed: /usr/local/google/home/jayconrod/.cache/bazel/_bazel_jayconrod/install/a7278b0d7ef44b43f6f09d38616a6ee6/_embedded_binaries/libunix.so: /usr/crosstool/v18/x86_64-grtev4-linux-gnu/lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /usr/local/google/home/jayconrod/.cache/bazel/_bazel_jayconrod/install/a7278b0d7ef44b43f6f09d38616a6ee6/_embedded_binaries/libunix.so).  Possibly your installation has been corrupted.
java.lang.UnsatisfiedLinkError: /usr/local/google/home/jayconrod/.cache/bazel/_bazel_jayconrod/install/a7278b0d7ef44b43f6f09d38616a6ee6/_embedded_binaries/libunix.so: /usr/crosstool/v18/x86_64-grtev4-linux-gnu/lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /usr/local/google/home/jayconrod/.cache/bazel/_bazel_jayconrod/install/a7278b0d7ef44b43f6f09d38616a6ee6/_embedded_binaries/libunix.so)
	at java.lang.ClassLoader$NativeLibrary.load(Native Method)
	at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1948)
	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1857)
	at java.lang.Runtime.loadLibrary0(Runtime.java:870)
	at java.lang.System.loadLibrary(System.java:1122)
	at com.google.devtools.build.lib.UnixJniLoader.loadJni(UnixJniLoader.java:28)
	at com.google.devtools.build.lib.unix.ProcessUtils.<clinit>(ProcessUtils.java:28)
	at com.google.devtools.build.lib.util.ProcessUtils.getpid(ProcessUtils.java:47)
	at com.google.devtools.build.lib.runtime.BlazeRuntime.getPidUsingJNI(BlazeRuntime.java:1087)
	at com.google.devtools.build.lib.runtime.BlazeRuntime.maybeForceJNIByGettingPid(BlazeRuntime.java:1076)
	at com.google.devtools.build.lib.runtime.BlazeRuntime.maybeGetPidString(BlazeRuntime.java:1069)
	at com.google.devtools.build.lib.runtime.BlazeRuntime.main(BlazeRuntime.java:583)
	at com.google.devtools.build.lib.bazel.BazelMain.main(BazelMain.java:60)
ERROR: <unknown> crash in async thread:
java.lang.UnsatisfiedLinkError: /usr/local/google/home/jayconrod/.cache/bazel/_bazel_jayconrod/install/a7278b0d7ef44b43f6f09d38616a6ee6/_embedded_binaries/libunix.so: /usr/crosstool/v18/x86_64-grtev4-linux-gnu/lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /usr/local/google/home/jayconrod/.cache/bazel/_bazel_jayconrod/install/a7278b0d7ef44b43f6f09d38616a6ee6/_embedded_binaries/libunix.so)
	at java.lang.ClassLoader$NativeLibrary.load(Native Method)
	at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1948)
	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1857)
	at java.lang.Runtime.loadLibrary0(Runtime.java:870)
	at java.lang.System.loadLibrary(System.java:1122)
	at com.google.devtools.build.lib.UnixJniLoader.loadJni(UnixJniLoader.java:28)
	at com.google.devtools.build.lib.unix.ProcessUtils.<clinit>(ProcessUtils.java:28)
	at com.google.devtools.build.lib.util.ProcessUtils.getpid(ProcessUtils.java:47)
	at com.google.devtools.build.lib.runtime.BlazeRuntime.getPidUsingJNI(BlazeRuntime.java:1087)
	at com.google.devtools.build.lib.runtime.BlazeRuntime.maybeForceJNIByGettingPid(BlazeRuntime.java:1076)
	at com.google.devtools.build.lib.runtime.BlazeRuntime.maybeGetPidString(BlazeRuntime.java:1069)
	at com.google.devtools.build.lib.runtime.BlazeRuntime.main(BlazeRuntime.java:583)
	at com.google.devtools.build.lib.bazel.BazelMain.main(BazelMain.java:60)
@katre

This comment has been minimized.

Member

katre commented Feb 20, 2018

@jayconrod

This comment has been minimized.

Collaborator

jayconrod commented Feb 20, 2018

Thanks John, that fixed all my problems on Linux.

On macOS, I was able to reproduce an error in the tests mentioned above. Looked something like this:

ERROR: /private/var/tmp/_bazel_jayconrod/548507d80176b200ef38a28d692a3690/external/io_bazel_rules_go/tests/legacy/gc_opts_unsafe/BUILD.bazel:54:1: C++ compilation of rule '@io_bazel_rules_go//tests/legacy/gc_opts_unsafe:unsafe_cgo_lib.cgo_c_lib' failed (Exit 1): wrapped_clang failed: error executing command 
  (cd /private/var/tmp/_bazel_jayconrod/548507d80176b200ef38a28d692a3690/execroot/bazel_test && \
  exec env - \
    APPLE_SDK_PLATFORM='' \
    APPLE_SDK_VERSION_OVERRIDE='' \
    PATH=.:/Users/jayconrod/bin:/usr/local/go/bin:/Users/jayconrod/go/bin:/usr/local/git/current/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/local/go/bin \
    XCODE_VERSION_OVERRIDE=8.3.3 \
  external/local_config_cc/wrapped_clang '-D_FORTIFY_SOURCE=1' -fstack-protector -fcolor-diagnostics -Wall -Wthread-safety -Wself-assign -fno-omit-frame-pointer -O0 -DDEBUG -iquote external/io_bazel_rules_go -iquote bazel-out/darwin-fastbuild/genfiles/external/io_bazel_rules_go -iquote external/bazel_tools -iquote bazel-out/darwin-fastbuild/genfiles/external/bazel_tools -isystem external/bazel_tools/tools/cpp/gcc3 -MD -MF 'bazel-out/darwin-fastbuild/bin/external/io_bazel_rules_go/tests/legacy/gc_opts_unsafe/_objs/unsafe_cgo_lib.cgo_c_lib/external/io_bazel_rules_go/tests/legacy/gc_opts_unsafe/darwin_amd64_stripped/unsafe_cgo_lib.cgo_codegen~/unsafe_cgo.cgo2.d' '-isysroot __BAZEL_XCODE_SDKROOT__' -I external/io_bazel_rules_go/tests/legacy/gc_opts_unsafe -Wno-unused-variable -no-canonical-prefixes -Wno-builtin-macro-redefined '-D__DATE__="redacted"' '-D__TIMESTAMP__="redacted"' '-D__TIME__="redacted"' -c 'bazel-out/darwin-fastbuild/bin/external/io_bazel_rules_go/tests/legacy/gc_opts_unsafe/darwin_amd64_stripped/unsafe_cgo_lib.cgo_codegen~/unsafe_cgo.cgo2.c' -o 'bazel-out/darwin-fastbuild/bin/external/io_bazel_rules_go/tests/legacy/gc_opts_unsafe/_objs/unsafe_cgo_lib.cgo_c_lib/external/io_bazel_rules_go/tests/legacy/gc_opts_unsafe/darwin_amd64_stripped/unsafe_cgo_lib.cgo_codegen~/unsafe_cgo.cgo2.o' -c 'bazel-out/darwin-fastbuild/bin/external/io_bazel_rules_go/tests/legacy/gc_opts_unsafe/darwin_amd64_stripped/unsafe_cgo_lib.cgo_codegen~/unsafe_cgo.cgo2.c' -o 'bazel-out/darwin-fastbuild/bin/external/io_bazel_rules_go/tests/legacy/gc_opts_unsafe/_objs/unsafe_cgo_lib.cgo_c_lib/external/io_bazel_rules_go/tests/legacy/gc_opts_unsafe/darwin_amd64_stripped/unsafe_cgo_lib.cgo_codegen~/unsafe_cgo.cgo2.o')
clang: error: cannot specify -o when generating multiple output files
Target @io_bazel_rules_go//tests/legacy/gc_opts_unsafe:unsafe_cgo_lib failed to build

Seems that -c and -o options are repeated when building a cc_library rule.

These libraries are built in somewhat obscure circumstances. We build a script that creates a temporary directory, copies WORKSPACE and BUILD.bazel files there that reference the original workspace (via local_repository), then build rules with sources from the original workspace. The purpose of this is to check that Bazel can be invoked with certain command line flags and we'll get certain results. We need to do this in a separate repo with a separate output base so we can run the test with Bazel. The mechanics of this are in tests/bazel_tests.bzl.

A problem I saw was that the test was using the installed bazel binary (~/bin/bazel for me) instead of the binary I built from source. When I installed the version built from source, the issue went away.

Have there been any recent changes that would affect systems with multiple versions of Bazel? I expect that this is probably more of an issue with CI than with Bazel itself.

@buchgr

This comment has been minimized.

Contributor

buchgr commented Feb 21, 2018

Jay,

thanks so much for debugging this! We'll set up our CI so that the bazel in the PATH always refers to the Bazel used for testing. cc: @philwo

@laszlocsomor

This comment has been minimized.

Contributor

laszlocsomor commented Mar 9, 2018

Can we close this?

@philwo

This comment has been minimized.

Member

philwo commented Mar 9, 2018

Not yet, this is still broken.

@laszlocsomor

This comment has been minimized.

Contributor

laszlocsomor commented Mar 12, 2018

Thanks Philipp! Do you know who's working on it?

@buchgr buchgr closed this Mar 21, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment