Building software to be relocatable (was: Re: During Migration to Arm64 mac, should I null out archs='x86_64' from installed ports list?)

[Ryan Schmidt]

On Apr 14, 2022, at 04:57, Richard L. Hamilton wrote:

> Would use of @loader_path as in @loader_path/../lib or whatever when linking binaries (and something similar for linking between libraries within MacPorts) not be a big part of  making it so the executables and libraries didn't embed where the tree lived? There would doubtless be other changes to make it possible  to move /opt/local without breaking pre-built binaries, but that might be a big part of  it. And it could be started one port at a time, long before everything needed to be done to make that possible.

Yes, using @loader_path, @executable_path, or (on 10.5 and later) @rpath would be the way to make the executables and libraries support a relocatable prefix.

https://itwenty.me/2020/07/understanding-dyld-executable_path-loader_path-and-rpath/

But the prefix is often baked into software in other places as well. For example you might tell a program at build time where it should look for its data files, and it might record that as an absolute path within a config file that's installed or even just as a string embedded in a library or executable. See https://trac.macports.org/ticket/56204 for an example of this (in MacPorts itself).

MacPorts makes no effort to build ports in a relocatable fashion and changing MacPorts to do so would probably be a huge undertaking.

We have at times had ports that used @rpath by default. This often ended up causing problems. See https://trac.macports.org/query?summary=~@rpath