https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90834
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> --- > --- 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? > CC="clang --sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk" > CXX="clang++ --sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk" > > work? > (without the symlink hacks) The CC/CXX part won't be necessary with clang: it finds its headers without /usr/include just fine. > The version-specific /Library/Developer/CommandLineTools/SDKs/MacOSX.10.XX.sdk > is (so far) just a symlink to the generic name Seems to be a symlink to the native OS version files indeed. > (presumably, you can't make the symlink hacks without switching SIP off > .. and [IMO] switching SIP off should not be a pre-requisite for building / > testing a toolchain > FWIW, SIP is on all my systems except a Darwin17 one with VirtualBox which > won't function there under SIP... It never was meant to be any sort of solution at all, just a hack to get me further along. I don't even remember when/why I turned it off initially. > * I don't have Xcode installed on most of my systems, nor the command line > tools, so most of my config lines look something like the above [with paths > for > the SDK to where I've placed it] (if that no longer works, then ...) While I do have Xcode installed, it's mostly there for xcode-select and stuff... I do have the command line tools installed regularly to avoid having to play games to find headers and startup objects (well, before now ;-) > (not disagreeing that we need a way to handle this, but neither turning gcc's > driver into xcrun ... nor using several extra process launches, per > invocation.. seems a useful way) Absolutely: I'd have hoped that there's a programmatic way to get at that info. I haven't found one while checking llvm/clang sources, though, but a dtruss on clang (I think) found a symlink in /var/db/... pointing to the SDK. If there's nothing better, that certainly beats calling xcrun every time...
