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
