https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90834
--- Comment #8 from Iain Sandoe <iains at gcc dot gnu.org> --- (In reply to Iain Sandoe from comment #6) > (In reply to r...@cebitec.uni-bielefeld.de from comment #5) > > > --- Comment #1 from Iain Sandoe <iains at gcc dot gnu.org> --- > > > I don't have 10.15 or xcode 11 yet .. > > > > No worry: I just happened to upgrade for reasons unrelated to gcc work > > and gave it a whirl... > > > > > does ... > > > configure --prefix ... > > > --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk > > > ..... > > > > Haven't tried that yet. I can once the current bootstrap (which is > > still running) has completed. > > > > However, isn't --with-sysroot to completely override the system headers, > > so any standard library in /usr/lib won't be found any longer? > > On some platforms, that might/would be the effect. However, on Darwin > platforms the two-level namespace in libraries means that the recorded path > at link time is found in the exe at runtime (and the SDKs contain the > relevant paths for the runtimes to be found in /). > > AFAIK, there's no "global" ability to rebase the found libraries into a > different tree at runtime (modulo the use of DYLD_LIBRARY_PATH, which is > doubly inadvisable in the face of SIP and sandboxing of various dirs). To expand upon this - on Darwin - the use of --with-sysroot= does *not* cause the use of a different dynamic linker, found in the rooted path (as it would on Linux, for example). I think this is intentional, not merely a historical artefact. Apropos "can't do a global change" - In fact, it *is* possible to provide a different dynamic linker path per exe - but it's not something I've ever tried ... there are too many Frameworks etc. in / that are not reproducible in any reasonable timeframe.
