[Bug target/57792] toplevel configure should enable "--with-sysroot="`xcrun --show-sdk-path`"" for darwin13 and later

["howarth at bromo dot med.uc.edu" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792

--- Comment #19 from howarth at bromo dot med.uc.edu ---
(In reply to Hin-Tak Leung from comment #18)
> (In reply to mrs@gcc.gnu.org from comment #15)
> > Mandating commands line tools is fine.  Would be nice if everything worked
> > flawlessly if no optional package had to be installed, but I'm pragmatic.
> 
> The current behavior is definitely wrong: without command line tools and
> without --with-sysroot (i.e. just plain ./configure), ./configure returns
> success, but only fail to 'make' towards the end of stage1 when the build
> system tries to do the 'stage1-fixincludes' target.
> 
> ./configure should either auto-add the --with-sysroot (as the reverted fix
> did), or abort with an appropriate message, like the requirement for
> gmp/mpfr/mpc. successful ./configure then failing part-way through make is
> bad.
> 

The proper test to detect the missing Command Line Tools /usr/include files
should be added then.

> (In reply to howarth from comment #17)
> > You have to remember that Apple expects you to build everything from within
> > the Xcode projects while the Command Line Tools package exists to handle
> > building outside of that mechanism. The unfortunate fact is that far too
> > much software explicitly expects headers in /usr/include to avoid installing
> > the Command Line Tools. In the fink project, we get endless bug reports from
> > users who fail to install the Command Line Tools.
> 
> Not really. Actually xcode 6.1 seem to ships all the command line tools.
> doing 'xcode-select --install' install a much older(?) command line tools
> plus headers in /usr/include. I don't know if Apple is going to keep that
> in-sync, but there might be a danger of the headers in /usr/include not
> really describing the system.

You must have caught them before they synced. On my machine, I have synced
Xcode.app and Command Line Tools...

%
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
-v
Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.0.0
Thread model: posix

% /Library/Developer/CommandLineTools/usr/bin/clang -v
Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.0.0
Thread model: posix

from 'xcode-select --install'.

> 
> Also, people who DIY are supposed to go through all the troubles... you
> still haven't addressed the issue of new gcc (+ xcode building it with) may
> generate stuff that have additional dependencies on /usr/include, if
> /usr/include is around, and therefore not suitable when one is building
> things for others.

Are you assuming that folks are installing third-party stuff in /usr/include?
Since users should be installing only in /usr/local for that, that seems a bit
out of bounds here.