Dan Allen <danallen46@xxxxxxxxx> wrote:
On 18 Feb 2020, at 3:46 AM, Jonathan Wakely <jwakely.gcc@xxxxxxxxx> wrote:
From one of our darwin maintainers:
--with-sysroot=`xcrun --show-sdk-path` --…any other configure stuff
export SDKROOT=`xcrun --show-sdk-path`
Sadly, I tried all of the suggestions again, and none of them work.
I have bootstrapped yesterday and today on Catalina with the XCode 11.3
command line tools SDK.
see:
https://gcc.gnu.org/ml/gcc-testresults/2020-02/msg01132.html
FWIW, I tend to put the —with-sysroot= explicitly pointing to a specific
SDK on the command line (because I keep multiple versions of the SDK around
so that I can test problems with different revisions if needed).
—— something must be different for your case ...
Please could you file a PR with:
1) the version of XCode (or the command line tools) you have installed.
2) the output of xcrun --show-sdk-path
3) the configure line you are using
4) the output from the failed build
I am not alone. Google searches show that many people have encountered
this problem.
OK, let’s see … the folks I have so far spoken to who had the issue, have
been able to get successful bootstraps using —with-sysroot=
I believe that there need to be changes within the gcc source trees to
automatically detect the lack of /usr/include and to then go to plan B,
using xcrun to determine where /usr/include is really located, in order
for a full bootstrap build to work.
I am (presently) somewhat reluctant to do this because that means that the
compiler can be configured (automatically) with one SDK and then some
change occurs to the xcode or command line installation which alters the
premise on which it was configured. E.g. the user can update / move Xcode
and/or switch the command line tools to refer to a different version.
My (current) reasoning is that a need to add an explict "—with-sysroot=" to
the configure line would warn folks that if they change the SDK, then the
compiler they built with a different one, should be rebuilt - or
potentially expected to behave differently.
However, this is by no means a “final statement” it might be we can figure
out a warning that could be triggered on such a change.
cheers
Iain
