#29838 closed enhancement (fixed)
Use -headerpad_max_install_names in default configure.ldflags so that install_name_tool can relocate libraries
Reported by: | gellule.xg@… | Owned by: | macports-tickets@… |
---|---|---|---|
Priority: | Normal | Milestone: | MacPorts 2.2.0 |
Component: | base | Version: | 1.9.2 |
Keywords: | Cc: | su-v, help@…, ryandesign (Ryan Carsten Schmidt), cooljeanius (Eric Gallager) | |
Port: |
Description
"install_name_tool" changes dynamic shared library install names and/or adds, changes or deletes the rpaths recorded in a Mach-O binary. For this tool to work when the install names or rpaths are larger the binary should be built with the ld "headerpad_max_install_names" option. This tool can therefore be used to relocate a shared library outside of the macports tree.
The purpose of this ticket is to add to LDFLAGS the "-Wl,-headerpad_max_install_names" option for all ports. A simple approach would be to modify portconfigure.tcl by setting "default configure.ldflags" to:
default configure.ldflags {"-L${prefix}/lib -Wl,-headerpad_max_install_names"}
I haven't been able to identify a drawback to this default addition.
There is a thread related to this issue that mentions the fact that some ports do erase the default ldflags: http://lists.macosforge.org/pipermail/macports-dev/2011-March/thread.html#14202
This addition helps with relocation, but does not guarantee it: there could well be other aspects of the built libraries that are not compatible with a relocation.
Change History (11)
comment:1 Changed 12 years ago by su-v
Cc: | suv-sf@… added |
---|
comment:3 Changed 12 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | ryandesign@… added |
---|---|
Summary: | Generate shared libraries what can be processed with install_name_tool (one step toward shared library relocation) → Use -headerpad_max_install_names in default configure.ldflags so that install_name_tool can relocate libraries |
comment:4 Changed 12 years ago by ryandesign (Ryan Carsten Schmidt)
Milestone: | → MacPorts Future |
---|---|
Resolution: | → fixed |
Status: | new → closed |
I've been using this modification for the past 3 weeks without any problems, so I committed it in r104258.
comment:6 Changed 12 years ago by jmroot (Joshua Root)
The drawback is that the users who want to relocate will have an expectation that it should work with every port now.
comment:7 follow-ups: 8 9 10 Changed 12 years ago by ryandesign (Ryan Carsten Schmidt)
It already should have worked with cmake ports, and now it'll hopefully work with most autoconf ports too. Users can file tickets for individual ports where it doesn't work.
comment:8 Changed 12 years ago by raimue (Rainer Müller)
The prefix path might still be hardcoded in the binaries and libraries for external resources in share
or additional helper scripts/binaries in libexec
. Also the interpreter paths are hardcoded in the #!
lines for scripts. Even with this flag it's not possible to relocate ports to another prefix.
This change targets a very limited audience wanting to rip out libraries out of MacPorts and use them in a different path. Using this flag does probably not cause any harm, but we should be cautious not to give the impression that it's now possible to relocate ports to a different prefix.
Replying to ryandesign@…:
It already should have worked with cmake ports, and now it'll hopefully work with most autoconf ports too. Users can file tickets for individual ports where it doesn't work.
We need to discuss the policy on this (maybe move that discussion to macports-dev?). Do we expect all ports to use -Wl,-headerpad_max_install_names?
comment:9 Changed 12 years ago by jmroot (Joshua Root)
Replying to ryandesign@…:
Users can file tickets for individual ports where it doesn't work.
Yes, exactly.
comment:10 Changed 12 years ago by devernay (Frédéric Devernay)
Note that it helps a lot when building a distributable app that uses MacPorts libraries, or libraries that use lots of plugins (e.g. ImageMagick). The "macdeployqt" utility from qt4-mac does this kind of job, but only deals with Qt libraries and plugins. I had to locally modify ports to make it possible, and I'm happy if it gets integrated in the next release.
comment:11 Changed 11 years ago by jmroot (Joshua Root)
Milestone: | MacPorts Future → MacPorts 2.2.0 |
---|
Cc Me!