[Bug target/90835] Incompatibilities with macOS 10.15 headers

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #26 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #25 from Iain Sandoe <iains at gcc dot gnu.org> ---
> (In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #24)
>> > --- Comment #23 from Iain Sandoe <iains at gcc dot gnu.org> ---
>> > unpatched GCC master, gcc-9.x, gcc-8.x and gcc-7.5 work for me with any
>> > SDK >=
>> > Xcode commandline tools 11.3b.
>> 
>> I've recently tried both building gcc 8.3.0 (build only) and master
>> (full bootstrap and test) on macOS 10.14.6 and 10.15.3, each with Xcode
>> 11.3.1.  Both worked *provided the build and target compilers were
>> configured with the approriate --with-sysroot to account for the lack of
>> /usr/include and startup objects in /usr/lib*.
>
> That's not going to change, I think (at least, the underlying behaviour).

Indeed, we'll have to live with that.

> We could entertain and implement a change to Darwin's configuration that
> automatically discovers the /Library/Developer/CommandLineTools .. or
> /Applications/Xcode... for Darwin versions >= X and complains of fails to
> configure if those can't be seen (asking for a --with-sysroot=).

That's one option, certainly easier for the users.  At the least, the
issue should be documented in install.texi so they can add
--with-sysroot manually if need be.  I just noticed that the install
docs only have a small section on PowerPC Darwin, nothing else...

> We can already invoke GCC like "xcrun /path/to/gcc-exe" provided that is not
> called "gcc" or "g++" it will work to set the SDKROOT which gcc honours from
> 7.5+.
>
> The only irritation is that we can't use 'gcc' or 'g++' in that position,
> because xcrun places the clang/++ aliases ahead of the GCC in the PATH (even if
> the GCC install is first) [last time I tried].

Sounds like a bad mess and totally unexpected.  Besides, the additional
exec will have some cost.  No idea how measurable it would be for a
bootstrap, though.

> There's also an API to obtain the info - but only on 10.15+ and it forces one
> to install XCode I suspect to use it, I'm not keen on making new dependencies
> on things outside our control - I'd rather make use of OSS equivalents.

Understood.  In particular when Xcode.app can be installed anywhere, not
just in /Applications.  Maybe something to talk about with Jeremy
Sequoia, perhaps it can be provided from some stable location?