Reason for rpath usage on arm64

Ken Cunningham ken.cunningham.webuse at
Tue May 24 15:22:32 UTC 2022

> Does anyone know why things seem to be using rpath on arm64 builds

Basically, it comes down to the fact that Apple has disallowed DYLD_LIBRARY_PATH to work on newer systems.

gcc for Darwin has one developer working on it, practically. Iain. He has been maintaining it for 10+ years, wrote the objective C implementation it uses, and is pretty much the only reason gcc works on Darwin at all. Perhaps someone would fill his shoes if he stopped doing it, hard to say.

He maintains hardware machines from 10.5 to the current, and he tries to keep as many versions of gcc as possible running on as many systems as he can.

Once Apple disallowed DYLD_LIBRARY_PATH, he has had a lot of trouble running the test suites on the gcc libraries, as he can’t force the libraries under test to be the ones used. Instead the libraries installed are the ones used, which means he has to actually install the gcc before testing it.

Multiply that by perhaps 6 active gcc versions on each system, and 50+ test runs of gcc weekly, and you can see the problem.

Using @rpath gets around that problem very nicely.

Now, LLVM and many other software projects have the same issue. They also use @rpath to do it. But on INSTALLATION these @rpaths can be rewritten automatically by cmake (or meson) to be full pathnames. So that is what MacPorts does.

gcc’s build system does not currently offer that installation option. I don’t know how hard it would be to add it (any volunteers?) but for now at least, Iain is not keen on adding that @rpath rewrite-on-install business to gcc.

So gcc is installing it’s libraries with the @rpath linkages — it’s not just arm, by the way. It’s just arm right now because that is the tip of the spear. Very soon ALL gcc installs will use @rpaths, as that is (for now, barring a better option) the only way Iain can maintain gcc at all on Darwin.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the macports-dev mailing list