[Bug target/57792] toplevel configure should enable --with-sysroot=`xcrun --show-sdk-path` for darwin13 and later
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.
[Bug target/57792] toplevel configure should enable --with-sysroot=`xcrun --show-sdk-path` for darwin13 and later
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792 --- Comment #14 from Hin-Tak Leung htl10 at users dot sourceforge.net --- (In reply to howarth from comment #13) If we made any change, I would rather it be a check in FSF gcc's configure for the presence of /usr/include on darwin which provided the appropriate error message to the user that the Command Line Tools needs to be installed. I don't think mandating Command Line Tools would be a good idea - I think in that case you can have a reverse problem when your intention is to build stuff for other people: you build x intended for others, you have /usr/include but others don't, x made assumptions about the intended users having the same stuff as yours, and it doesn't work on the intended user's machine, or have mysterious errors.
[Bug target/57792] toplevel configure should enable --with-sysroot=`xcrun --show-sdk-path` for darwin13 and later
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792 --- Comment #15 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org --- 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.
[Bug target/57792] toplevel configure should enable --with-sysroot=`xcrun --show-sdk-path` for darwin13 and later
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792
Iain Sandoe iains at gcc dot gnu.org changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Comment #16 from Iain Sandoe iains at gcc dot gnu.org ---
(In reply to m...@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.
I'd agree with pragmatism every time.
OTOH,
(a) it would be nice to have a heads up on the thinking going forward (would
have been possible to ask filks last week).
(b) it is apparent that there's a move towards desiring a uniform interface
where the {native}host is considered just another target with its own SDK.
I kinda like the uniformity too.
[Bug target/57792] toplevel configure should enable --with-sysroot=`xcrun --show-sdk-path` for darwin13 and later
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792 --- Comment #17 from howarth at bromo dot med.uc.edu --- (In reply to Hin-Tak Leung from comment #14) (In reply to howarth from comment #13) If we made any change, I would rather it be a check in FSF gcc's configure for the presence of /usr/include on darwin which provided the appropriate error message to the user that the Command Line Tools needs to be installed. I don't think mandating Command Line Tools would be a good idea - I think in that case you can have a reverse problem when your intention is to build stuff for other people: you build x intended for others, you have /usr/include but others don't, x made assumptions about the intended users having the same stuff as yours, and it doesn't work on the intended user's machine, or have mysterious errors. 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.
[Bug target/57792] toplevel configure should enable --with-sysroot=`xcrun --show-sdk-path` for darwin13 and later
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792 --- Comment #18 from Hin-Tak Leung htl10 at users dot sourceforge.net --- (In reply to m...@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. (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. 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.
[Bug target/57792] toplevel configure should enable --with-sysroot=`xcrun --show-sdk-path` for darwin13 and later
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 m...@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.
[Bug target/57792] toplevel configure should enable --with-sysroot=`xcrun --show-sdk-path` for darwin13 and later
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792 --- Comment #13 from howarth at bromo dot med.uc.edu --- Yes, I am pretty sure Apple has abandoned this for good. They only attempted the change because it was assumed to be completely transparent as the compiler looks in /usr/include by default. It wasn't appreciated that this would cause... radr://14320107 /usr/bin/python reports back include directories that are unpopulated where removal of /usr/include caused the system Python.h to point to an unpopulated header directory in INCLUDEPY. While I provided them with a patch to sysconfig.py to solve this, there is no stomach at Apple for pushing such changes upstream as other packages like perl that hardcode compiler options will need to be modified as well. While we could add this change to FSF gcc, I don't think we want to encourage users not to install the system headers in /usr/include via the Command Line Tools of Xcode as there are other configure scripts out there which will also need to be patched to find /usr/include with `xcrun --show-sdk-path`. If we made any change, I would rather it be a check in FSF gcc's configure for the presence of /usr/include on darwin which provided the appropriate error message to the user that the Command Line Tools needs to be installed.
[Bug target/57792] toplevel configure should enable --with-sysroot=`xcrun --show-sdk-path` for darwin13 and later
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792 howarth at bromo dot med.uc.edu changed: What|Removed |Added CC||howarth at bromo dot med.uc.edu --- Comment #10 from howarth at bromo dot med.uc.edu --- (In reply to Hin-Tak Leung from comment #9) Did the change make it into 4.9.2? I recently tried that and found that I need the explicit --sysroot: https://gcc.gnu.org/ml/gcc-testresults/2014-11/msg00268.html Otherwise it fails during the stage1-fixincludes stage. (luckily I saw the tips and reference to this bug report in the older buildstat). This change was reverted when Apple abandoned the idea of removing the /usr/include. They didn't appreciate the number of packages (like python) which would require the changes to also find the new location of the /usr/include.
[Bug target/57792] toplevel configure should enable --with-sysroot=`xcrun --show-sdk-path` for darwin13 and later
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792 --- Comment #11 from howarth at bromo dot med.uc.edu --- (In reply to Hin-Tak Leung from comment #9) Did the change make it into 4.9.2? I recently tried that and found that I need the explicit --sysroot: https://gcc.gnu.org/ml/gcc-testresults/2014-11/msg00268.html Also, if you can't find /usr/include on OS X, that means you need to install the Command Line Tools with 'xcode-select --install'.
[Bug target/57792] toplevel configure should enable --with-sysroot=`xcrun --show-sdk-path` for darwin13 and later
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792 --- Comment #12 from Hin-Tak Leung htl10 at users dot sourceforge.net --- (In reply to howarth from comment #10) This change was reverted when Apple abandoned the idea of removing the /usr/include. They didn't appreciate the number of packages (like python) which would require the changes to also find the new location of the /usr/include. (In reply to howarth from comment #11) Also, if you can't find /usr/include on OS X, that means you need to install the Command Line Tools with 'xcode-select --install'. Have Apple really abandoned the idea of removing /usr/include ? xcode 6.1 ships all the headers under the SDK places; indeed as you said, running 'xcode-select --install' prompts for installing the command line developer's tools, which seems to install /usr/include ; but the Command Line Developer's Tool installed this way is only version 5.1 (i.e. against an older version of xcode, I think). Also I think it could be a bit more user friendly - e.g. test for the existence of /usr/include, and set --with-sysroot=\`xcrun --show-sdk-path`\ if /usr/include does not exist? It isn't much more code, but would make a lot of difference in user-friendliness.
[Bug target/57792] toplevel configure should enable --with-sysroot=`xcrun --show-sdk-path` for darwin13 and later
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792 Hin-Tak Leung htl10 at users dot sourceforge.net changed: What|Removed |Added CC||htl10 at users dot sourceforge.net --- Comment #9 from Hin-Tak Leung htl10 at users dot sourceforge.net --- Did the change make it into 4.9.2? I recently tried that and found that I need the explicit --sysroot: https://gcc.gnu.org/ml/gcc-testresults/2014-11/msg00268.html Otherwise it fails during the stage1-fixincludes stage. (luckily I saw the tips and reference to this bug report in the older buildstat).
[Bug target/57792] toplevel configure should enable --with-sysroot=`xcrun --show-sdk-path` for darwin13 and later
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792 mrs at gcc dot gnu.org mrs at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Version|unknown |4.8.0 Resolution|--- |FIXED --- Comment #8 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org --- Fixed.
[Bug target/57792] toplevel configure should enable --with-sysroot=`xcrun --show-sdk-path` for darwin13 and later
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792 Jack Howarth howarth at nitro dot med.uc.edu changed: What|Removed |Added Summary|fixincludes doesn't honor |toplevel configure should |the use of --with-sysroot |enable |during bootstrap|--with-sysroot=`xcrun ||--show-sdk-path` for ||darwin13 and later --- Comment #4 from Jack Howarth howarth at nitro dot med.uc.edu --- Sorry for the noise. The addition of… --with-sysroot=`xcrun --show-sdk-path` in fact does allow fixincludes to find the buried usr/include. I'm not sure what other option I was passing that prevented that from working before. I have switched this PR to an enhancement request for modifying the top level configure.ac to pass… --with-sysroot=`xcrun --show-sdk-path` for darwin13 or later. I am unclear how this can be done considering that the top level configure.ac doesn't mention --with-sysroot. However I am sure we should be passing it down from there to insure that all of the other configure files get that option set.
[Bug target/57792] toplevel configure should enable --with-sysroot=`xcrun --show-sdk-path` for darwin13 and later
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792
--- Comment #5 from Jack Howarth howarth at nitro dot med.uc.edu ---
I am really surprised the following change if insufficient to replace manually
passing…
--with-sysroot=`xcrun --show-sdk-path`
to configure on the command line for darwin13...
Index: configure.ac
===
--- configure.ac(revision 200683)
+++ configure.ac(working copy)
@@ -2848,6 +2848,13 @@ if test x${is_cross_compiler} = xyes ; t
target_configargs=--with-cross-host=${host_noncanonical}
${target_configargs}
fi
+case ${target} in
+ x86_64-*-darwin13*)
+target_configargs=--with-sysroot=\`xcrun --show-sdk-path`\
${target_configargs}
+;;
+esac
+
+
# Default to --enable-multilib.
if test x${enable_multilib} = x ; then
target_configargs=--enable-multilib ${target_configargs}
Index: configure
===
--- configure (revision 200683)
+++ configure (working copy)
@@ -7414,6 +7414,13 @@ if test x${is_cross_compiler} = xyes ; t
target_configargs=--with-cross-host=${host_noncanonical}
${target_configargs}
fi
+case ${target} in
+ x86_64-*-darwin13*)
+target_configargs=--with-sysroot=\`xcrun --show-sdk-path`\
${target_configargs}
+;;
+esac
+
+
# Default to --enable-multilib.
if test x${enable_multilib} = x ; then
target_configargs=--enable-multilib ${target_configargs}
This patch (without explicitly passing --with-sysroot to configure) results in
the fixincludes complaining about not finding /usr/include again but the
top-level config.log shows target_configargs has
--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX10.9.sdk on it.
Should I be appending --with-sysroot=\`xcrun --show-sdk-path`\ to different
variable instead?
[Bug target/57792] toplevel configure should enable --with-sysroot=`xcrun --show-sdk-path` for darwin13 and later
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792 --- Comment #6 from Jack Howarth howarth at nitro dot med.uc.edu --- (In reply to Jack Howarth from comment #5) The same change of adding --with-sysroot=\`xcrun --show-sdk-path`\ to build_configargs also fails when fix_includes tries to find /usr/include. Strangely, adding --with-sysroot=\`xcrun --show-sdk-path`\ to host_configargs allows fixincludes to find the headers but then dies in stage2 with the cryptic error… Configuring stage 2 in ./intl Configuring stage 2 in ./libiberty Configuring stage 2 in ./libbacktrace Configuring stage 2 in ./libdecnumber make[4]: Nothing to be done for `all'. make[3]: Nothing to be done for `all'. configure: loading cache ../config.cache configure: loading cache ../config.cache configure: loading cache ../config.cache configure: loading cache ../config.cache configure: error: `CC' has changed since the previous run:
[Bug target/57792] toplevel configure should enable --with-sysroot=`xcrun --show-sdk-path` for darwin13 and later
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792
--- Comment #7 from Jack Howarth howarth at nitro dot med.uc.edu ---
(In reply to Jack Howarth from comment #6)
My mistake in mixing host_configargs and build_configargs. The following patch
works fine…
Index: configure.ac
===
--- configure.ac(revision 200683)
+++ configure.ac(working copy)
@@ -2848,6 +2848,13 @@ if test x${is_cross_compiler} = xyes ; t
target_configargs=--with-cross-host=${host_noncanonical}
${target_configargs}
fi
+# Pass --with-sysroot on darwin without SDK in /
+case ${target} in
+ x86_64-*-darwin1[[3-9]]*)
+host_configargs=--with-sysroot=\`xcrun --show-sdk-path`\
${host_configargs}
+;;
+esac
+
# Default to --enable-multilib.
if test x${enable_multilib} = x ; then
target_configargs=--enable-multilib ${target_configargs}
