_solib_ symlinks differ between Bazel 6 and Bazel 7 with --noenable_bzlmod about bazel HOT 4 OPEN

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?

from bazel.

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.

from bazel.

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.

from bazel.

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 : )

from bazel.