Building gcc on macOS 10.15 Catalina is stage 1 only

[Iain Sandoe]

Dan Allen <danallen46@gmail.com> wrote:

>> On 18 Feb 2020, at 3:46 AM, Jonathan Wakely <jwakely.gcc@gmail.com> 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