https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030
--- Comment #16 from Eric Gallager <egallager at gcc dot gnu.org> --- (In reply to Iain Sandoe from comment #15) > 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. At least personally I'd like to get away from the "using Xcode" part some day... > > 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.
