Use -headerpad_max_install_names in default configure.ldflags so that install_name_tool can relocate libraries

[gellule.xg@…]

"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.

[su-v]

Cc Me!

[help@…]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

This has been requested before/again for some individual ports like ffmpeg (#23372), opencv (#36841), tiff (#38202). If it doesn't cause problems, as claimed above, maybe we should be doing this globally.

[ryandesign (Ryan Carsten Schmidt)]

I've been using this modification for the past 3 weeks without any problems, so I committed it in r104258.

[cooljeanius (Eric Gallager)]

Cc Me!

[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.

[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.

[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?

[jmroot (Joshua Root)]

Replying to ryandesign@…:

Users can file tickets for individual ports where it doesn't work.

Yes, exactly.

[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.