Skip to content
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
Closed

Bazel HEAD breaks rules_go on macOS #4659

buchgr opened this issue Feb 19, 2018 · 8 comments
Labels

Comments

@buchgr
Copy link
Contributor

@buchgr 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
Copy link
Collaborator

@jayconrod jayconrod commented Feb 20, 2018

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

@jayconrod
Copy link
Collaborator

@jayconrod 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
Copy link
Member

@katre katre commented Feb 20, 2018

@jayconrod
Copy link
Collaborator

@jayconrod 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
Copy link
Contributor Author

@buchgr 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
Copy link
Contributor

@laszlocsomor laszlocsomor commented Mar 9, 2018

Can we close this?

@philwo
Copy link
Member

@philwo philwo commented Mar 9, 2018

Not yet, this is still broken.

@laszlocsomor
Copy link
Contributor

@laszlocsomor 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
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants