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

Give libraries @rpath-relative install names #4371

Closed
Birch-san opened this Issue Jun 22, 2018 · 1 comment

Comments

Projects
None yet
2 participants
@Birch-san
Copy link

Birch-san commented Jun 22, 2018

Shared libraries should be optimized for sharing.

I have a common use-case:

  • install a library using Brew
  • link my software to it
  • distribute a portable release of my software, shipping brew libraries alongside my executable

The spanner in the works is the install_name upon brew-installed libraries.

A library's install name recommends, "anybody who links to me should look for me at this path".
Problematically: brew libraries prescribe absolute paths. Environment-specific.

====

Suppose I brew install libvorbis.

I link my executable to libvorbis.dylib.
The linker writes into my executable "look for libvorbis at /usr/local/opt/libvorbis/lib/libvorbis.0.dylib".

I cannot give that executable to my friend. It's not portable.

====

Proposal: give every library an @rpath-relative install name. Like @rpath/libvorbis.dylib.
I have full control over how my executable expands @rpath (its runtime search path).

For example: my executable may expand @rpath to @executable_path/lib. I can make a folder "lib" relative to my executable, and copy brew libraries into it. The resulting package is portable, and may be given to my friend.

This even works for brew libraries which depend on other brew libraries. libvorbis.dylib could link to libogg.dylib using @rpath/libogg.dylib; this strategy would allow vorbis to find ogg even when both libraries are inside my project's lib folder, and even when moved to my friend's computer.

====

A nice aspect of @rpath expansion is that it supports fallbacks. So, libvorbis.dylib can propose an rpath expansion of /usr/local/opt/libogg/lib.

Thus, vorbis could still locate its dependency ogg in the usual absolute manner. Describing the relationship in terms of @rpath does not break that behaviour.

So, we can maintain compatibility yet add flexibility.

====

Currently on my projects, I have to use post-build scripts like this or this to work around this inflexibility of brew libraries. These scripts are enormous and fragile. They require a lot of manual effort and verification.

I am not the only person to try and automate around this. Mine is not the only project affected by non-portable linking.

====

I hope I've managed to convey the problem and proposal correctly. Please say so if you'd like any clarification.

@MikeMcQuaid

This comment has been minimized.

Copy link
Member

MikeMcQuaid commented Jun 23, 2018

Please always fill out the issue template in future.

We do not build for redistribution; rpath is not the only issue you will find with redistributing Homebrew creating libraries (e.g. cflags). We may accept PRs that make this easier but this isn’t something the maintainers will be working on or we’re soliciting help with.

@lock lock bot added the outdated label Jul 23, 2018

@lock lock bot locked as resolved and limited conversation to collaborators Jul 23, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.