Bazel 0.15.0 breaks C++ linking on MacOS

[jmillikin-stripe]

Description of the problem / feature request:

After updating to Bazel 0.15.0, C++ binaries are being linked with the flag -Wl,-no-as-needed which does not exist in the MacOS linker.

$ bazel-0.15.0 build //:hello
ERROR: /Users/jmillikin/src/test-bazel-gcc/BUILD:1:1: Linking of rule '//:hello' failed (Exit 1)
ld: unknown option: -no-as-needed
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Target //:hello failed to build
Use --verbose_failures to see the command lines of failed build steps.

$ cc --version
Apple LLVM version 10.0.0 (clang-1000.10.25.5)
Target: x86_64-apple-darwin17.4.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

$ ld -v
@(#)PROGRAM:ld  PROJECT:ld64-408.1.1
BUILD 05:18:43 May 25 2018
configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em
LTO support using: LLVM version 10.0.0, (clang-1000.10.25.5) (static support for 21, runtime is 21)
TAPI support using: Apple TAPI version 10.0.0 (tapi-1000.0.7.3)

What operating system are you running Bazel on?

MacOS

What's the output of bazel info release?

release 0.15.0

[jmillikin-stripe]

It looks like the implementation of _is_linker_option_supported() is broken for Apple's Clang:

diff --git a/tools/cpp/unix_cc_configure.bzl b/tools/cpp/unix_cc_configure.bzl
index 3141b0bc25..4bee5743c9 100644
--- a/tools/cpp/unix_cc_configure.bzl
+++ b/tools/cpp/unix_cc_configure.bzl
@@ -171,6 +171,7 @@ def _is_linker_option_supported(repository_ctx, cc, option):
         "/dev/null",
         str(repository_ctx.path("tools/cpp/empty.cc")),
     ])
+    print("_is_linker_option_supported(option=%r): %r" % (option, result.stderr))
     return result.stderr.find(option) == -1
 
 def _is_gold_supported(repository_ctx, cc):

$ ~/src/bazel/bazel-bin/src/bazel_with_jdk build //:hello
Extracting Bazel installation...
Starting local Bazel server and connecting to it...
...................
DEBUG: /private/var/tmp/_bazel_jmillikin/e6f0c92ab1a4f1ce77362e0f9e692d78/external/bazel_tools/tools/cpp/unix_cc_configure.bzl:174:5: _is_linker_option_supported(option="-Wl,-no-as-needed"): "ld: unknown option: -no-as-needed\nclang: error: linker command failed with exit code 1 (use -v to see invocation)\n"
DEBUG: /private/var/tmp/_bazel_jmillikin/e6f0c92ab1a4f1ce77362e0f9e692d78/external/bazel_tools/tools/cpp/unix_cc_configure.bzl:174:5: _is_linker_option_supported(option="-Wl,-z,relro,-z,now"): "ld: unknown option: -z\nclang: error: linker command failed with exit code 1 (use -v to see invocation)\n"

Note that the stderr reports the flag as -no-as-needed, but the configuration logic is looking for the -Wl, prefixed version.

[jin]

cc @laurentlb (RM)

[soonho-tri]

I've hit the same issue, ld: unknown option: -no-as-needed. FYI,

• On OSX-10.13.5 (with clang-902.0.39.2), I don't have this problem.
• On OSX-10.12.6 (with clang-900.0.39.2), I can reproduce the problem.
• On OSX-10.11.6 (with clang-800.0.42.1), I can reproduce the problem.

[RNabel]

Can confirm, 0.15.0 working with clang-902.0.39.2.

[hlopko]

@laurentlb Can/Should we have a patch release for this? I'll work on the fix.

[yuikns]

I am on OSX-10.13.5 (with clang-902.0.39.2), but still get a broken.

[hectim]

Same thing happened to me, brew didn't have the versions I wanted to try so I removed it and installed from source like described here.
protocolbuffers/protobuf#4841

Downgrading to bazel 0.14.1 fixed it

[hlopko]

@laurentlb FYI: this is now fixed.

[oferb]

@mhlopko In which version of Bazel is it fixed?

[hlopko]

@oferb only at HEAD. That's why I pinged Laurent, to consider a patch release. But since we're cutting 0.16 soon, maybe it's not needed.

@buchgr (release manager for 0.16) Can you make sure the fix makes it into 0.16?

[buchgr]

@c-parsons is the release manager for 0.16.0. I suggest you ping the usual release issue.

[jmillikin-stripe]

@hectim @mhlopko I don't think this is fixed, the above PR merely changed which linker flag is incorrectly allowed:

ERROR: /private/var/tmp/_bazel_jmillikin/272411befdf8076e3a18b870d1a93c0f/external/com_google_protobuf/BUILD.bazel:399:1: Linking of rule '@com_google_protobuf//:js_embed' failed (Exit 1)
ld: unknown option: -z
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Note that the cc -Wl,-z,relro,-z,now generates an error about -z only, not mentioning the rest of the flag string.

[ittaiz]

Any thoughts? Given that downgrading brew is not a fun task this is becoming somewhat of a sore thumb

…

On Thu, 5 Jul 2018 at 22:11 jmillikin-stripe ***@***.***> wrote: @hectim <https://github.com/hectim> @mhlopko <https://github.com/mhlopko> I don't think this is fixed, the above PR merely changed which linker flag is incorrectly allowed: ERROR: /private/var/tmp/_bazel_jmillikin/272411befdf8076e3a18b870d1a93c0f/external/com_google_protobuf/BUILD.bazel:399:1: Linking of rule ***@***.***_google_protobuf//:js_embed' failed (Exit 1) ld: unknown option: -z clang: error: linker command failed with exit code 1 (use -v to see invocation) Note that the cc -Wl,-z,relro,-z,now generates an error about -z only, not mentioning the rest of the flag string. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#5468 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABUIFz_vBaY2w_RJNevBmAVO-W0J9aqmks5uDmTFgaJpZM4U4W3E> .

[hlopko]

Ouch. Can you pls verify it's fixed now?

[jmillikin-stripe]

Bazel at head (with your second commit) works on my machine.

[hlopko]

Thanks so much!

[ittaiz]

any idea when 0.16.0 will be released? We have users constantly hitting this so maybe a patch release would help

[johnynek]

+1 we’d love a patch release. 0.16 is great but there is not guarantee I won’t also have as yet undiscovered issues.

Seems this is exactly what patch releases are for.

[buchgr]

cc @laurentlb

[dslomov]

+1 to patch release

[laurentlb]

OK, I can prepare a patch release.

[terinjokes]

@laurentlb Is there a ticket to track the patch release? This is still causing problems for us.

[laurentlb]

See #5591