Opened 13 years ago

Closed 12 years ago

Last modified 11 years ago

#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

Cc Me!

comment:2 Changed 12 years ago by help@…

Cc: help@… added

Cc Me!

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

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.

comment:4 Changed 12 years ago by ryandesign (Ryan Carsten Schmidt)

Milestone: MacPorts Future
Resolution: fixed
Status: newclosed

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

comment:5 Changed 12 years ago by cooljeanius (Eric Gallager)

Cc: egall@… added

Cc Me!

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 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 in reply to:  7 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 in reply to:  7 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 in reply to:  7 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 FutureMacPorts 2.2.0
Note: See TracTickets for help on using tickets.