bazelbuild
v 5 cc_library, linkstatic=False fails to emit .so file
Description of the bug:
Under version 4.2.0, the following emits libalpha.a and libalpha.so
cc_library( name = "alpha", srcs = [ "alpha.c", ], linkstatic = False, )
Under version 5 and up, it only emits libalpha.a
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
In a fresh directory:
.bazelversion
4.2.0
BUILD.bazel:
cc_library(
name = "alpha",
srcs = [
"alpha.c",
],
linkstatic = False,
)
WORKSPACE.bazel:
## empty
alpha.c:
int my_int_fn()
{ return 17; }
Then, setting .bazelversion to 4.2.0:
$ bazel clean --expunge
INFO: Starting clean.
$ bazel version
Bazelisk version: development
Starting local Bazel server and connecting to it...
Build label: 4.2.0
Build target: bazel-out/darwin-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Wed Aug 18 12:54:03 2021 (1629291243)
Build timestamp: 1629291243
Build timestamp as int: 1629291243
$ bazel build :alpha
INFO: Analyzed target //:alpha (16 packages loaded, 139 targets configured).
INFO: Found 1 target...
Target //:alpha up-to-date:
bazel-bin/libalpha.a
bazel-bin/libalpha.so
INFO: Elapsed time: 8.916s, Critical Path: 0.32s
INFO: 6 processes: 3 internal, 3 darwin-sandbox.
INFO: Build completed successfully, 6 total actions
Change .bazelversion to 5.0.0:
$ bazel clean --expunge
Starting local Bazel server and connecting to it...
INFO: Starting clean.
$ bazel version
Bazelisk version: development
Starting local Bazel server and connecting to it...
Build label: 5.0.0
Build target: bazel-out/darwin-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Wed Jan 19 14:15:55 2022 (1642601755)
Build timestamp: 1642601755
Build timestamp as int: 1642601755
$ bazel build :alpha
INFO: Analyzed target //:alpha (36 packages loaded, 239 targets configured).
INFO: Found 1 target...
Target //:alpha up-to-date:
bazel-bin/libalpha.a
INFO: Elapsed time: 13.195s, Critical Path: 0.28s
INFO: 4 processes: 2 internal, 2 darwin-sandbox.
INFO: Build completed successfully, 4 total actions
Same result for .bazelversion 5.3.0, latest, and last_green
Which operating system are you running Bazel on?
MacOS Monterey 12.5.1
What is the output of bazel info release?
Depends on what's in .bazelversion
If bazel info release returns development version or (@non-git), tell us how you built Bazel.
Tested with .bazelversion last_green, which gives:
$ bazel info release
2022/09/13 13:40:31 Using unreleased version at commit fdcaaf4af3296bf544589810ad46b438bfe5e1fb
development version
$ bazel version
2022/09/13 13:41:45 Using unreleased version at commit fdcaaf4af3296bf544589810ad46b438bfe5e1fb
Bazelisk version: development
Build target: bazel-out/darwin-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Thu Jan 01 00:00:00 1970 (0)
Build timestamp: Thu Jan 01 00:00:00 1970 (0)
Build timestamp as int: 0
What's the output of git remote get-url origin; git rev-parse master; git rev-parse HEAD ?
$ git remote get-url origin; git rev-parse master; git rev-parse HEAD
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
### Have you found anything relevant by searching the web?
No
### Any other information, logs, or outputs that you want to share?
Posted a message on the dissussion list: [https://groups.google.com/g/bazel-discuss/c/qD5yU6VbvYI/m/zldlaP35AgAJ?utm_medium=email&utm_source=footer](https://groups.google.com/g/bazel-discuss/c/qD5yU6VbvYI/m/zldlaP35AgAJ?utm_medium=email&utm_source=footer)
I thought this could be explained by rewriting cc_library to Starlark but as far as I can see the logic is the same. See here and here.
Is dynamic linking enabled in your toolchain?
@keith have you noticed anything similar on Mac yourself?
On Fri, Sep 16, 2022 at 7:38 AM oquenchil @.***> wrote:
I thought this could be explained by rewriting cc_library to Starlark but as far as I can see the logic is the same. See here https://cs.opensource.google/bazel/bazel/+/master:src/main/starlark/builtins_bzl/common/cc/cc_library.bzl;drc=eb181661ff7e72781f46b7994a5e5c9bab45d5dd;l=239-260 and here https://cs.opensource.google/bazel/bazel/+/master:src/main/java/com/google/devtools/build/lib/rules/cpp/CcLibrary.java;drc=3e13f4cbb60bfcd7edd3949184cda42f0785fe54;l=414-435 .
Is dynamic linking enabled in your toolchain?
Not sure what you mean. I'm not using a custom toolchain, just whatever bazel discovers on my Mac, which is just the xcode toolchain.
@keith https://github.com/keith have you noticed anything similar on Mac yourself?
— Reply to this email directly, view it on GitHub https://github.com/bazelbuild/bazel/issues/16271#issuecomment-1249312358, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAES2NGRV74KUHXIKDYSI5DV6RS5NANCNFSM6AAAAAAQLWZMSE . You are receiving this because you authored the thread.Message ID: @.***>
The default mac toolchain stopped supporting dynamic linking in 5.0: ec5553352
I hadn't noticed this, but that commit looks pretty intentional about disabling this 🤔
On Fri, Sep 16, 2022 at 9:55 AM pcjanzen @.***> wrote:
The default mac toolchain stopped supporting dynamic linking in 5.0: ec55533 https://github.com/bazelbuild/bazel/commit/ec5553352f2f661d39ac4cf665dd9b3c779e614c
What does that mean? Pretty sure Apple did not stop supporting .so files or dlopen. cc_binary with linkshared=True seems to work. I don't fully understand the problem that change was supposed to fix, but it is a breaking change. Anyway "stop supporting dynamic linking" and "make cc_library stop emitting .so files" are different things, from my perspective.
— Reply to this email directly, view it on GitHub https://github.com/bazelbuild/bazel/issues/16271#issuecomment-1249470753, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAES2NFZBSHF5XXPQE3RL6TV6SC5LANCNFSM6AAAAAAQLWZMSE . You are receiving this because you authored the thread.Message ID: @.***>
The feature "supports_dynamic_linker" is poorly named, but it only controls whether cc_library emits this "nodeps" .so file.
There is a lot more detail in https://github.com/bazelbuild/bazel/issues/4341#issuecomment-758028203.
TL;DR these .so files do not work properly on Apple platforms. I believe if you want functional .so files you should use cc_binary(..., linkshared=1) or cc_shared_library.
