Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

#13427 Broke mac C++ toolchains #15214

Closed
det opened this issue Apr 11, 2022 · 2 comments
Closed

#13427 Broke mac C++ toolchains #15214

det opened this issue Apr 11, 2022 · 2 comments
Assignees
Labels

Comments

@det
Copy link
Contributor

det commented Apr 11, 2022

Description of the bug:

The only use of runtime_solib_name in the bazel repo is this:

tools/osx/crosstool/cc_toolchain_config.bzl:                            "-Wl,-install_name,@rpath/%{runtime_solib_name}",

This line is now broken.

The way it worked previously is bazel will inject rpaths into an executable, ie:

path @loader_path/../../_solib_arm64/

This directory contains symlinks for all the mangled names of shared libraries that have been built.

This can only work if the install_name for a shared library is set to the mangled name. #13427 changes it so that runtime_solib_name is no longer mangled. ie, it went from libexternal_Sboost_Slibasio.dylib to libasio.dylib.

Also, the test as it existed was also correct as cc_test will link its dependencies using dynamic linking by default. The new test is broken as it does not capture the use case this feature was written to support (and I expect the change caused the test to start failing before it was rewritten).

Also see the description of the variable:

  /** The name of the runtime solib symlink of the shared library. */
  RUNTIME_SOLIB_NAME("runtime_solib_name");

which states that it is the mangled name that exists in the _solib_* dir.

Can we please revert #13427? @csmulhern @oquenchil

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

No response

Which operating system are you running Bazel on?

Macos

What is the output of bazel info release?

5.1.1

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 master; git rev-parse HEAD ?

No response

Have you found anything relevant by searching the web?

No response

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

No response

@det
Copy link
Contributor Author

det commented Apr 11, 2022

cc @Yannic (Looks like you made the original feature)

@det
Copy link
Contributor Author

det commented Apr 14, 2022

@oquenchil Created a PR (#15261) to revert this change, required minimal manual fixup after the revert to get it to compile.

ckolli5 added a commit that referenced this issue May 10, 2022
This reverts commit b06f495.

Also had to add a missing mnemonic function call parameter to `getDynamicLibrarySoname`. Copy-pasted the parameter from the other use of that function in the codebase.

Tested manually with a custom toolchain and there is also a test from the reverted code.

Fixes #15214

Closes #15261.

PiperOrigin-RevId: 446662219

Co-authored-by: Chris Clearwater <[email protected]>
meteorcloudy pushed a commit that referenced this issue May 10, 2022
This reverts commit b06f495.

Also had to add a missing mnemonic function call parameter to `getDynamicLibrarySoname`. Copy-pasted the parameter from the other use of that function in the codebase.

Tested manually with a custom toolchain and there is also a test from the reverted code.

Fixes #15214

Closes #15261.

PiperOrigin-RevId: 446662219

Co-authored-by: Chris Clearwater <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants