https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88590
--- Comment #4 from Iain Sandoe <iains at gcc dot gnu.org> --- (In reply to Iain Sandoe from comment #0) > Possible fix #1 > =============== > > This is what I've been tinkering with > > 1) convert all the target libraries to use @rpath/libxxxxx.dylib as their > install names > 2) get GCC to emit the necessary rpaths into executables during build and > test (and, obviously, at install time). > > Actually, this is sensibly in line with a useful macOS deployment model - > since the "approved" way to package shared libraries on macOS / Darwin is to > place them alongside the executables and use rpaths. > > unfortunately: > * it's quite an involved set of changes and almost certainly not going to > happen for 9. > * there are details to work out to make sure that build-time paths don't > leak into installed libraries/exes. tested and working fix posted here: https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584775.html > Possible fix #2 > =============== > > Have a build environment where all the used executables and paths are > outside the remit of SIP. This is untested so far, and might not suit the > casual user of GCC - since it would involve building at least a shell / make > / GCC prerequisites etc. Not going to work - /bin/sh is hardwired into configure scripts.
