Which release supported installation destinations?

[Ryan Schmidt]

On Sep 14, 2018, at 00:12, Mojca Miklavec wrote:

> On Fri, 14 Sep 2018 at 06:18, Joshua Root wrote:
>> 
>> On 2018-9-14 13:49 , George Plymale II wrote:
>>> Also, I'm curious. You said that I'll lose the ability to get binary
>>> packages. Which element of this setup causes compilation to become
>>> necessary: a source-based installation or running MacPorts in a
>>> non-standard prefix?
>> 
>> The prefix. Our binary archives are built for the default prefix
>> /opt/local and simply extracting them somewhere else often (usually?)
>> won't work. That's not because of anything MacPorts does, but just
>> because software that is not carefully constructed to be relocatable
>> will have installation paths "baked in" in many places.
> 
> It's worth noting though that HB tries very hard to make the
> majority(?) of packages relocatable. Lots of libraries would only need
> a couple of install_name_tool calls. It's something that would be nice
> in MacPorts as well if anyone with sufficient knowledge was willing to
> work on that .

What does Homebrew do, specifically, to accomplish that?

Since MacPorts 2.2.0 we put -Wl,-headerpad_max_install_names into the default configure.ldflags. See https://trac.macports.org/ticket/29838. Ports that honor the default configure.ldflags can then have their libraries relocated by running install_name_tool on the libraries and the executables that use them.

Not all ports use the default configure.ldflags; those that don't probably should.

There are a limitless variety of other ways that installation paths might be baked into the files installed by a particular port, as determined by the whims of its developers. If the paths are baked into text files, it is likely that just replacing the original installation path with the new installation path would be sufficient. However if the path is baked into binary files, such as Mach-O executables or libraries, in ways other than those that can be addressed by install_name_tool, it is likely that doing that would corrupt the file, since such files tend to contain offsets to other parts of the file which replacing one path with a shorter or longer path would invalidate.

MacPorts could conceivable be enhanced to offer some binaries to non-standard prefixes. It could download the binary that was built for the standard prefix, attempt to use install_name_tool to fix the binaries, and use reinplace to fix the text files. It could then check if there are any remaining occurrences of the standard prefix, and if so, bail and build from source. We could even allow ports to define a block of code to do any needed custom path-fixing.

I am not working on that, but I am at least working on making the MacPorts base installer relocatable, so that users who want to install to a custom prefix can do so without needing to build MacPorts base from source.