v 5 cc_library, linkstatic=False fails to emit .so file

[mobileink]

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)

[mobileink]

For the record, I prefer the 4.2.0 way, emitting both files.

[oquenchil]

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?

[mobileink]

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 <#16271 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAES2NGRV74KUHXIKDYSI5DV6RS5NANCNFSM6AAAAAAQLWZMSE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[pcjanzen]

The default mac toolchain stopped supporting dynamic linking in 5.0: ec55533

[keith]

I hadn't noticed this, but that commit looks pretty intentional about disabling this 🤔

[mobileink]

On Fri, Sep 16, 2022 at 9:55 AM pcjanzen ***@***.***> wrote: The default mac toolchain stopped supporting dynamic linking in 5.0: ec55533 <ec55533>

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 <#16271 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAES2NFZBSHF5XXPQE3RL6TV6SC5LANCNFSM6AAAAAAQLWZMSE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[oquenchil]

@trybka Do you have some background for this?

[trybka]

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 #4341 (comment).

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.