https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030
--- Comment #15 from Iain Sandoe <iains at gcc dot gnu.org> --- FWIW I had a quick look the other day if there was an easy fix to this PR, and didn't find a '5 minute' one. (In reply to Eric Gallager from comment #14) > (In reply to Iain Sandoe from comment #13) > > (In reply to Jeremy Huddleston Sequoia from comment #12) > > > (In reply to Francois-Xavier Coudert from comment #11) > > > > (In reply to Jeremy Huddleston Sequoia from comment #10) > > Of course, one *can* pass --sysroot=`xcrun blah blah` on any command line > > (for the built compiler) as a work-around. > > > > I was trying to work on a scheme where the possible SDK search paths were > > provided by symlinks [in the user's home dir], with some configure-time > > specified search order (including the option to search /). Initial > > population of the symlinks might be time-significant - but subsequent > > following should be less than a process switch. There was some email > > exchange on this between me, Eric and Mike .. I will try to find it in my > > archives. > > You found it yet? Yes... it's in my (unfortunately large) stack of things to be forward-ported. Please see also comments on PR79885 Also making a proper fix for PR84257 might involve reorganising things (in particular shifting from using absolute library paths to @rpath ones, for 10.5+ [not available on 10.4]). IMO, we really need to set out how we want Darwin toolchains to behave for the end user, and then figure out how to make the build and test work to support that. This is non-trivial in the presence of SIP, user-movable packages, and the library naming scheme. Still working on this.. but equally open to suggestions. It's certainly true that one use-case is "build a self-hosted GCC using Xcode" but that's definitely not the only scenario, and we [some of us at least] don't want to be locked into it. The other fact of life is that there are now such significant discrepancies between darwin versions from 8 .. 18 that we might no longer be able to avoid multi-libs to support the range properly.
