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

building dynamic libraries on mac sets id/name for linker to something questionable #121674

Open
vmchale opened this issue Feb 27, 2024 · 3 comments
Labels
A-linkage Area: linking into static, shared libraries and binaries O-macos Operating system: macOS T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@vmchale
Copy link

vmchale commented Feb 27, 2024

If I build a "cdylib", it tells the linker that the library is located in the target/release directory.

Here is the output for otool -l:

Load command 4
          cmd LC_ID_DYLIB
      cmdsize 96
         name /Users/vanessa/dev/rust/forks/regex/target/release/deps/librure.dylib (offset 24)
   time stamp 1 Wed Dec 31 19:00:01 1969
      current version 0.0.0
compatibility version 0.0.0

This means I can't install the shared library by copying the .dylib to /usr/local/lib; I have to run install_name_tool on the build result before distributing.

I think building a library should set the name to something like @rpath/librure.dylib

@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Feb 27, 2024
@fmease fmease added A-linkage Area: linking into static, shared libraries and binaries O-macos Operating system: macOS T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. and removed needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. labels Mar 1, 2024
@bjorn3
Copy link
Member

bjorn3 commented Mar 1, 2024

Duplicate of #28640? #114445 seems related too.

@vmchale
Copy link
Author

vmchale commented Mar 2, 2024

Duplicate of #28640? #114445 seems related too.

I think it's related to #28640 but not a duplicate. The linker command in this case is LC_ID_DYLIB rather than LC_LOAD_DYLIB.

I think it's different from #114445 since this is about rustc's output rather than rustc itself, though the problem with rustcs output is mentioned in one of the comments.

@bjorn3
Copy link
Member

bjorn3 commented Mar 6, 2024

I don't think rustc tells the linker to set the install name to any value.

I think building a library should set the name to something like @rpath/librure.dylib

I just found that there is already an unstable option for this: -Zosx-rpath-install-name Rustc itself is built with this option enabled.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-linkage Area: linking into static, shared libraries and binaries O-macos Operating system: macOS T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants