_solib_ symlinks differ between Bazel 6 and Bazel 7 with --noenable_bzlmod

[dws]

Description of the bug:

With the attached example repo, I see the following with Bazel 6:

$ $bazel6 run --noenable_bzlmod -- //:debug
[...]
INFO: Running command line: bazel-bin/debug
.
./_solib_k8
./_solib_k8/_U@foo_S_S_Cbar___U
./_solib_k8/_U@foo_S_S_Cbar___U/bar.so
./debug
./debug.sh

and the following with Bazel 7:

$ $bazel7 run --noenable_bzlmod -- //:debug
[...]
INFO: Running command line: bazel-bin/debug
.
./_solib_k8
./_solib_k8/_U@@foo_S_S_Cbar___U
./_solib_k8/_U@@foo_S_S_Cbar___U/bar.so
./debug
./debug.sh

where the symlink paths differ due to @ vs @@.

Is this intentional? Or is this a bug?

Which category does this issue belong to?

C++ Rules

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

repro.tar.gz

Which operating system are you running Bazel on?

Ubuntu 20.04

What is the output of bazel info release?

release 7.1.1 (and release 6.2.0)

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse HEAD ?

No response

Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.

It broke certain hardcoded references to the single-@ symlink paths in the repo where I'm working. What's not clear is whether this incompatibility between Bazel 6 and Bazel 7 was intentional or unintentional.

Have you found anything relevant by searching the web?

no

Any other information, logs, or outputs that you want to share?

No response

[fmeum]

Is this intentional? Or is this a bug?

Not a C++ rules owner, but I would guess the answer is "neither": This is a result of the changes to label stringification that come with Bzlmod, but the solib paths are also more of an implementation detail of the cc rules.

Could you describe your use case for hardcoding these paths in the first place?

[comius]

That's more due to bzlmod than any requirements within C++ rules. It could be changed back. But also paths like this shouldn't be hard coded IMO.

[werkt]

I think the use of an @@ pathname was unexpected when we had not enabled bzlmod. It looked like an omission that had pulled behavior in for bzlmod without consideration of the option itself.

[dws]

Is this intentional? Or is this a bug?

Not a C++ rules owner, but I would guess the answer is "neither": This is a result of the changes to label stringification that come with Bzlmod, but the solib paths are also more of an implementation detail of the cc rules.

Could you describe your use case for hardcoding these paths in the first place?

The use case, which I inherited and will not attempt to defend, was as follows:

We have a rule that runs protoc, and tells it to run a Python binary of ours as a plugin. I'll call it //:A. The //:A Python binary in turn wanted to run a prebuilt executable @B//:B from an external repository. This @B//:B binary needs a libtinfo.so.5 shared object, and this happens to be in yet a different external repository. In order to allow @B//:B to run, the code in //:A had set up LD_LIBRARY_PATH by calling the Python runfiles library with the hardcoded _solib_ path to libtinfo.so.5 (relative to the root of the runfiles, naturally), and then taking the dirname of the result since LD_LIBRARY_PATH needs to list directories and not files.

This hardcoded _solib_ path had a single @, so when the mangled path started to contain @@ instead in Bazel 7, even when bzlmod was disabled, this portion of our build failed because @B//:B failed to run, and so //:A bailed out with an error, and so protoc bailed out with an error. It was a merry chase to figure out why : )