bazelbuild / bazelbuild/bazel

Expose CC solib name mangling in Skylark

Open
#4,581 4 comments 3 reactions 0 assignees View on GitHub
P3 team-Rules-CPP type: feature request
Dominant language
Java
Stars
25.8k
Forks
4.6k
Avg merge
2d 20h
Merged PRs (30d)
72

Description

### Description of the feature request

If a `cc_binary` depends on a dynamic library called `libfoo.so` produced by a `cc_library` target, one can notice that the binary _does not_ depend directly on `libfoo.so`, but instead of something like `libsome_Sname_Sbased_Son_Slabel_libfoo.so`. The reason for this is to avoid issues when two targets both build a `libfoo.so` and the binary depends on both. This mangling of the library name is performed by `SolibSymlinkAction.getMangledName()`.

This functionality should somehow be exposed to Skylark. That is to say, either make the mangled name the default output of a `cc_library`, instead of the non-mangled one as currently, or expose some extra functions in the Skylark standard library to let the user perform the same mangling in the same way that the built-in rules do and using the same workspace-global `_solib_` folder where the mangled symlinks are put.

### Feature requests: what underlying problem are you trying to solve with this feature?

Dynamically linking the output of a `cc_library` using Skylark rules is currently dangerous. It works most of the time, until it breaks because two users created libraries with the same name somewhere in the workspace. Since the `cc_*` rules do the right thing to avoid solib ambiguity, it would be nice if Skylark rules could do so as well out-of-the-box without having to reinvent their own mangling.

### What operating system are you running Bazel on?

NixOS Linux.

### What's the output of `bazel info release`?

`release 0.9.0- (@non-git)`

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

`nix-env -iA nixpkgs.bazel`

### Have you found anything relevant by searching the web?

Nothing that I could find in GitHub issues.

Contributor guide

Open the contributing guide

Research direction

Start by reading SolibSymlinkAction.getMangledName() and the existing cc_binary and cc_library handling of dynamic libraries. Trace how mangled symlinks are placed in the workspace-global _solib_ folder and how Skylark exposes related functionality. Done means Skylark rules can safely reproduce the built-in solib name mangling without ambiguity.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
build-system
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.