Building software to be relocatable (was: Re: During Migration to Arm64 mac, should I null out archs='x86_64' from installed ports list?)
ryandesign at macports.org
Thu Apr 14 21:22:08 UTC 2022
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.
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
More information about the macports-users