http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57753
--- Comment #1 from Jack Howarth <howarth at nitro dot med.uc.edu> ---
I should also note that removal of SDK from / isn't as bad as it sounds. In
general, most builds can puzzle out the location of the necessary headers.
However, FSF gcc is a complex build (especially regarding the fix includes
step) and in the absence of using xrcun, something like...
darwinvers=`sw_vers -productVersion | cut -d. -f1-2`
if [[ $darwinvers > 10.8 ]]; then
if [ -d /Library/Developer/CommandLineTools ]; then
configure CPPFLAGS="-O2 -g -isysroot `xcode-select
--print-path`/SDKs/MacOSX$darwinvers.sdk"
--with-native-system-header-dir=`xcode-select
--print-path`/SDKs/MacOSX$darwinvers.sdk/usr/include CXXFLAGS="-O2 -g
-iframework `xcode-select
--print-path`/SDKs/MacOSX$darwinvers.sdk/System/Library/Frameworks"
else
configure CPPFLAGS="-O2 -g -isysroot `xcode-select
--print-path`/Platforms/MacOSX.platform/Developer/SDKs/MacOSX$darwinvers.sdk"
--with-native-system-header-dir=`xcode-select
--print-path`/Platforms/MacOSX.platform/Developer/SDKs/MacOSX$darwinvers.sdk/usr/include
CXXFLAGS="-O2 -g -iframework `xcode-select
--print-path`/Platforms/MacOSX.platform/Developer/SDKs/MacOSX$darwinvers.sdk/System/Library/Frameworks"
fi
else
configure
fi
has to be used. Note that using xrcun eliminates the need for end-user to
define where the SDK resides (i.e. in Xcode.app or Command Line Tools) as well
as avoiding the need to define which exact SDK release to use.
