Unknown option --start-lib on OSX when compiling TreeArtifacts using cc_library

[kkiningh]

Description of the problem:

When cc_library depends on a directory that contains C++ source files (created through declare_directory) Bazel emits the linker option --start-lib which is undefined for clang on OSX.

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

I have a minimal example in this repo.

$ git clone git@github.com:kkiningh/bazel_tree_issue.git
$ cd bazel_tree_issue
$ bazel build :test --subcommands=pretty_print
Starting local Bazel server and connecting to it...
INFO: Analysed target //:test (8 packages loaded).
INFO: Found 1 target...
SUBCOMMAND: # //:tree [action 'SkylarkAction tree']
(cd /private/var/tmp/_bazel_kkiningh/d1dac7b92d06857cd504ed22b1d9dcd5/execroot/bazel_tree_issue && \
  exec env - \
  /bin/bash \
    -c \
    'mkdir -p bazel-out/darwin-fastbuild/bin/tree')
SUBCOMMAND: # //:test [action 'Linking libtest.a']
(cd /private/var/tmp/_bazel_kkiningh/d1dac7b92d06857cd504ed22b1d9dcd5/execroot/bazel_tree_issue && \
  exec env - \
    APPLE_SDK_PLATFORM='' \
    APPLE_SDK_VERSION_OVERRIDE='' \
    PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/TeX/texbin:/opt/X11/bin:/Users/kkiningh/go/bin:/Users/kkiningh/.local/bin:/Users/kkiningh/go/bin:/Users/kkiningh/.local/bin \                   
    XCODE_VERSION_OVERRIDE=10.0.0 \
  external/local_config_cc/wrapped_ar \
    rcs \
    bazel-out/darwin-fastbuild/bin/libtest.a \
    -Wl,--start-lib \
    -Wl,--end-lib)
SUBCOMMAND: # //:test [action 'Linking libtest.so']
(cd /private/var/tmp/_bazel_kkiningh/d1dac7b92d06857cd504ed22b1d9dcd5/execroot/bazel_tree_issue && \
  exec env - \
    APPLE_SDK_PLATFORM='' \
    APPLE_SDK_VERSION_OVERRIDE='' \
    PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/TeX/texbin:/opt/X11/bin:/Users/kkiningh/go/bin:/Users/kkiningh/.local/bin:/Users/kkiningh/go/bin:/Users/kkiningh/.local/bin \                   
    XCODE_VERSION_OVERRIDE=10.0.0 \
  external/local_config_cc/cc_wrapper.sh \
    -fobjc-link-runtime \
    -Wl,-S \
    -shared \
    -o \
    bazel-out/darwin-fastbuild/bin/libtest.so \
    -Wl,--start-lib \
    -Wl,--end-lib \
    -headerpad_max_install_names \
    -lc++ \
    -no-canonical-prefixes \
    -undefined \
    dynamic_lookup)
INFO: From Linking libtest.a:
ar: -Wl,--start-lib: No such file or directory
ar: -Wl,--end-lib: No such file or directory
ERROR: /Users/kkiningh/Workspace/Research/bazel_tree_issue/BUILD:7:1: Linking of rule '//:test' failed (Exit 1)                                                                                                
ld: unknown option: --start-lib
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Target //:test failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 4.269s, Critical Path: 0.14s
INFO: 2 processes: 2 darwin-sandbox.
FAILED: Build did NOT complete successfully

What operating system are you running Bazel on?

$ sw_vers 
ProductName:    Mac OS X
ProductVersion: 10.13.6
BuildVersion:   17G65

$ clang --version
Apple LLVM version 10.0.0 (clang-1000.11.45.2)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

What's the output of bazel info release?

release 0.18.0rc8

Have you found anything relevant by searching the web?

There were some previous issues with --start-lib on OSX (see #2502), but I think my issue is different since I have no problem building otherwise. There is also an issue with tree artifacts leading to inconstant builds (see #5785).

[hlopko]

Hmm I know what's going on. We assume that tree artifacts (that what declare_directory creates) get compiled into a list of objects, but we never create linking action for them, we take them as a list, and therefore we implicitly depend on support for --start-lib/--end-lib. This works with the gold and lld linkers, but not the linker installed on mac by default. I take this as a core C++ issue. I don't think we'll get to fixing this in Q4 though.

[kkiningh]

Is there a workaround you can think of? I tried implementing a custom C++ rule with the cc_common API, but got stuck (see my stack overflow question here).

[github-actions]

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 2+ years. It will be closed in the next 14 days unless any other activity occurs or one of the following labels is added: "not stale", "awaiting-bazeler". Please reach out to the triage team (@bazelbuild/triage) if you think this issue is still relevant or you are interested in getting the issue resolved.

[ribrdb]

I just ran into this trying to use https://github.com/kkiningh/rules_verilator on macos.

[protos-gunzinger]

This is still a problem when trying to use a mingw toolchain on windows (e.g. winlibs or w64devkit prebuilt toolchains).

Any update on this?