https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792
--- Comment #20 from Iain Sandoe <iains at gcc dot gnu.org> ---
Unofficially (but after chatting with a couple of folks who know):
"It should be assumed that depending on /usr/{include,lib} is unreliable".
"The RightWay(™) for the system is deemed to be finding a suitable SDK root
from "wherever". Yes, it's recognised that this is somewhat of a pain."
===
IMO we need to have a design that recognises that we (darwin support in GCC)
have different objectives from Xcode.
difference: #1 we support N-K (where N == host OS version, and K might be +/-
some number > 1). This means that we want to be able to find SDKs for system
versions that might not be included in the "current" Xcode. I don't like the
idea of shoe-horning those (extra SDKs) into Xcode just so that it can find
them - although I know folks already do that.
- note that -mmacosx-version-min= and MACOSX_DEPLOYMENT_TARGET can go some way
towards achieving part of those objectives - but it won't (for example) let you
build for powerpc-darwin9 from x86-86-darwin13 [something I *do* often do].
difference #2 (at least I) have an objective that one day - hopefully not too
far away, we will be able to cross-build for darwin ( > 9 ;) ) from other
platforms, e.g. Linux.
To that end I think we need a coherent design to cater for GCC's needs.
My initial suggestion is that we don't try to (ab-)use sysroot for this, but
instead add a --with-SDK-root= option that may be specified multiple times. We
might eventually need the driver to try and find the best match for the SDK
given a User "-mmacosx-version-min" and maybe even (one day)
-mmacosx-version-max= ..
This should have fall-backs as follows:
xcrun … where that's available
/Developer/SDKs (Darwin <= 9)
/ - essentially 'hope for the best' with /usr/{include,lib}
I think there are adequate hooks in config/darwin-c.c to deal with this without
impacting any part of the compiler outside the port [but that's without having
tried it].
====
I tend to agree that developers have to be prepared to understand a little
about what their doing - but IMO the User of the compiler (someone just trying
to build her code) should not have to jump through hoops to achieve that - at
least for a host-native compile ;)
I know Mike is not a fan of new C/L options, so I'm open to counter-proposals.
