[Bug target/90835] Incompatibilities with macOS 10.15 headers

[egallager at gcc dot gnu.org via Gcc-bugs]

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

Eric Gallager  changed:

   What|Removed |Added

   Assignee|egallager at gcc dot gnu.org   |unassigned at gcc dot 
gnu.org
 Status|ASSIGNED|NEW

--- Comment #36 from Eric Gallager  ---
ok I've done as much as I feel like doing for the moment with
r14-3335-g9a5d1fceb86a61, so I'm unassigning for now; leaving open, though, as
Iain had some suggestions for improving things further...

[Bug target/90835] Incompatibilities with macOS 10.15 headers

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #35 from CVS Commits  ---
The master branch has been updated by Eric Gallager :

https://gcc.gnu.org/g:9a5d1fceb86a61c9ead380df89ce3c4ba387d2e5

commit r14-3335-g9a5d1fceb86a61c9ead380df89ce3c4ba387d2e5
Author: Eric Gallager 
Date:   Wed May 25 12:45:33 2022 -0400

improve error when /usr/include isn't found [PR90835]

This is a pretty simple patch that ought to help Darwin users understand
better why their build is failing when they forget to pass the
--with-sysroot= flag to configure.

gcc/ChangeLog:

PR target/90835
* Makefile.in: improve error message when /usr/include is
missing

[Bug target/90835] Incompatibilities with macOS 10.15 headers

[egallager at gcc dot gnu.org via Gcc-bugs]

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

Eric Gallager  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2023-August/
   ||627793.html
   Keywords||patch

--- Comment #34 from Eric Gallager  ---
Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627793.html

[Bug target/90835] Incompatibilities with macOS 10.15 headers

[iains at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #33 from Iain Sandoe  ---
(In reply to Eric Gallager from comment #32)
> (In reply to r...@cebitec.uni-bielefeld.de from comment #26)
> > 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...
> 
> 
> So wait, is the idea to add separate sections for each other architecture of
> Darwin supported? Or should we just have one architecture-independent Darwin
> section?

When musing over this, I was thinking perhaps to have a relatively small entry
[on the install webpage] for Darwin (replacing the powerpc-specific one) and
just put the headlines there with a link to a new page in the wiki where we
could expand upon things.

I think that we would, at least, need subsections for 
 darwin <= 10
 darwin 11..14
 darwin 15..19
 darwin 20+

since there are some differences (e.g earlier systems _must_ have the
installation into / to work properly, the middle set can have either the /
install or the --sysroot= case, and the set from darwin15+ must use the
--sysroot= )

there could be cause to want to describe stuff for powerpc, i686, x86_64 and
arm64 separately ..
.. that was why a pointer to a new wiki page seemed possibly a better solution
than much churn on the webpage.

[Bug target/90835] Incompatibilities with macOS 10.15 headers

[egallager at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #32 from Eric Gallager  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #26)
> 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...


So wait, is the idea to add separate sections for each other architecture of
Darwin supported? Or should we just have one architecture-independent Darwin
section?

[Bug target/90835] Incompatibilities with macOS 10.15 headers

[egallager at gcc dot gnu.org via Gcc-bugs]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |egallager at gcc dot 
gnu.org

--- Comment #31 from Eric Gallager  ---
(In reply to Iain Sandoe from comment #30)
> (In reply to Eric Gallager from comment #29)
> > (In reply to Eric Gallager from comment #28)
> > > (I recently got a new laptop and am now on Catalina and ran into this bug,
> > > so that's why I'm coming back to it)
> > 
> > (Thus, moving from WAITING to NEW)
> 
> perhaps you'd like to draft a documentation change?

For install.texi? Sure; taking.

[Bug target/90835] Incompatibilities with macOS 10.15 headers

[iains at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #30 from Iain Sandoe  ---
(In reply to Eric Gallager from comment #29)
> (In reply to Eric Gallager from comment #28)
> > (I recently got a new laptop and am now on Catalina and ran into this bug,
> > so that's why I'm coming back to it)
> 
> (Thus, moving from WAITING to NEW)

perhaps you'd like to draft a documentation change?
 (I'm happy to review, but extremely short of darwin-time right now, so
addressing backports and fixes as a priority).

[Bug target/90835] Incompatibilities with macOS 10.15 headers

[egallager at gcc dot gnu.org via Gcc-bugs]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #29 from Eric Gallager  ---
(In reply to Eric Gallager from comment #28)
> (I recently got a new laptop and am now on Catalina and ran into this bug,
> so that's why I'm coming back to it)

(Thus, moving from WAITING to NEW)

[Bug target/90835] Incompatibilities with macOS 10.15 headers

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||documentation

--- Comment #28 from Eric Gallager  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #26)
> > --- Comment #25 from Iain Sandoe  ---
> > 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...
> 

Adding "documentation" keyword for this part at least
(I recently got a new laptop and am now on Catalina and ran into this bug, so
that's why I'm coming back to it)

[Bug target/90835] Incompatibilities with macOS 10.15 headers

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #27 from Eric Gallager  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #26)
> > --- Comment #25 from Iain Sandoe  ---
> > (In reply to r...@cebitec.uni-bielefeld.de from comment #24)
> >> > --- Comment #23 from Iain Sandoe  ---
> >> > 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?

I think it has come up in some other bug...

[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  ---
> --- Comment #25 from Iain Sandoe  ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #24)
>> > --- Comment #23 from Iain Sandoe  ---
>> > 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?

[Bug target/90835] Incompatibilities with macOS 10.15 headers

[iains at gcc dot gnu.org]

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

--- Comment #25 from Iain Sandoe  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #24)
> > --- Comment #23 from Iain Sandoe  ---
> > 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).

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=).

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].



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.

> > If there's no additional information I propose we close this PR after 
> > another
> > week.
> 
> I guess that's fine.

I think we have the /usr/local/include issue tracked elsewhere.

[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 #24 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #23 from Iain Sandoe  ---
> 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*.

> If there's no additional information I propose we close this PR after another
> week.

I guess that's fine.

Thanks.
Rainer

[Bug target/90835] Incompatibilities with macOS 10.15 headers

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #23 from Iain Sandoe  ---
unpatched GCC master, gcc-9.x, gcc-8.x and gcc-7.5 work for me with any SDK >=
Xcode commandline tools 11.3b.

If there's no additional information I propose we close this PR after another
week.

[Bug target/90835] Incompatibilities with macOS 10.15 headers

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835
Bug 90835 depends on bug 92719, which changed state.

Bug 92719 Summary: MacOS 10.15 Catalina build fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92719

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

[Bug target/90835] Incompatibilities with macOS 10.15 headers

[iains at gcc dot gnu.org]

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

--- Comment #22 from Iain Sandoe  ---
(In reply to Jürgen Reuter from comment #21)
> (In reply to Iain Sandoe from comment #20)
> > As of XCode 11.3beta, the contained SDK works OK:
> > 
> > https://gcc.gnu.org/ml/gcc-testresults/2019-11/msg01439.html
> > 
> > We still have the underlying problems - which need to be addressed (so
> > please don't close this PR yet) - but for now using the latest SDK should
> > work.
> 
> "should work" means with the gcc svn trunk or with the patch posted in this
> ticket applied?  I would understand your remark that it should work without
> the applied patch, as it stands from the gcc trunk.

It works with unpatched trunk - as per the posted results.

[Bug target/90835] Incompatibilities with macOS 10.15 headers

[juergen.reuter at desy dot de]

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

--- Comment #21 from Jürgen Reuter  ---
(In reply to Iain Sandoe from comment #20)
> As of XCode 11.3beta, the contained SDK works OK:
> 
> https://gcc.gnu.org/ml/gcc-testresults/2019-11/msg01439.html
> 
> We still have the underlying problems - which need to be addressed (so
> please don't close this PR yet) - but for now using the latest SDK should
> work.

"should work" means with the gcc svn trunk or with the patch posted in this
ticket applied?  I would understand your remark that it should work without the
applied patch, as it stands from the gcc trunk.

[Bug target/90835] Incompatibilities with macOS 10.15 headers

[iains at gcc dot gnu.org]

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

--- Comment #20 from Iain Sandoe  ---
As of XCode 11.3beta, the contained SDK works OK:

https://gcc.gnu.org/ml/gcc-testresults/2019-11/msg01439.html

We still have the underlying problems - which need to be addressed (so please
don't close this PR yet) - but for now using the latest SDK should work.

[Bug target/90835] Incompatibilities with macOS 10.15 headers

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #19 from Eric Gallager  ---
*** Bug 92445 has been marked as a duplicate of this bug. ***

[Bug target/90835] Incompatibilities with macOS 10.15 headers

[egallager at gcc dot gnu.org]

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

--- Comment #18 from Eric Gallager  ---
Downstream MacPorts ticket related to this:
https://trac.macports.org/ticket/59113

[Bug target/90835] Incompatibilities with macOS 10.15 headers

[a.h.jaffe at gmail dot com]

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

a.h.jaffe at gmail dot com changed:

   What|Removed |Added

 CC||a.h.jaffe at gmail dot com

--- Comment #17 from a.h.jaffe at gmail dot com ---
Jeremy, any information on the ETA of the __OSX_AVAILABLE_STARTING fix? I've
got quite a few things I can't compile right now!

[Bug target/90835] Incompatibilities with macOS 10.15 headers

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835
Bug 90835 depends on bug 66970, which changed state.

Bug 66970 Summary: Add __has_builtin() macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66970

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug target/90835] Incompatibilities with macOS 10.15 headers

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

   Keywords||meta-bug
 Blocks||90709
 Depends on||66970

--- Comment #16 from Iain Sandoe  ---
I think to make this into a meta-bug, with dependencies on:

__has_builtin () -  PR 66970
__has_feature ()
__has_extension ()
__attribute__((__availability__()))
  which depends on __attribute__((__unavailable__(...)))

Martin Sebor has posted a patch for PR 66970 and i have patches in progress for
__has_fature/extension and __attribute__((__unavailable__()))

(I will create PRs for the other deps. in due course)

At the moment, I'm a bit reluctant to jam __has_ => 0 in Darwin startup
code, since that might well produce wrong effects on headers that are already
adjusted (i.e. the compiler would report that __has_xxx was defined, but that
all the facilities were non-existent - which is a different state from
reporting hat __has_xxx is not present).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66970
[Bug 66970] Add __has_builtin() macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90709
[Bug 90709] [meta-bug] GNU Objective C (C++) cannot consume current headers on
Darwin platforms.

[Bug target/90835] Incompatibilities with macOS 10.15 headers

[jeremyhu at macports dot org]

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

--- Comment #15 from Jeremy Huddleston Sequoia  
---
(In reply to John Marshall from comment #14)
> [In reply to Jeremy Huddleston Sequoia in comment #12]
> 
> In the future, please file radars for these problems and ping me directly if
> you want.  Issues in macOS headers don't get fixed if we don't know about
> them,
> and I'd prefer to fix the SDK itself than have GCC use fixup hacks.
> [snip]
> The __OSX_AVAILABLE_STARTING issue still exists in the GM SDK as it was never
> reported to Apple AFAIK.  I've filed a radar now to track it:
> .
> 
> Thanks for the advice. I reported this to Apple in early June (FB6125120),
> as noted in comment #4 above. Looking at it in
> feedbackassistant.apple.com today, there
> is no real indication anyone at Apple has ever read it. So that's
> unfortunate.

Thanks for the pointer to your report, John.

I looked it up, and an engineer sent it back to ADC a couple weeks after you
filed it as a duplicate of .  51499580 is the one I
filed (actually on the same day as yours) for the __has_builtin usage in
Availability.h AvailabilityInternal.h and TargetConditionals.h.  Those were
addressed, but that wasnt't the entirety of the issues across the entire SDK.

The comments in the report were unfortunately not as detailed as the comments
in this bugzilla report, so the engineer that screened it just thought it was
addressed with the fix to the bug I reported.  Sorry we missed that, and I'm
sorry that ADC hasn't responded back to you.  I'm going to ping them to figure
out why this is still in their "send a response" queue.

As for bullets in Rainer's original report here, I believe #2,#4 were addressed
by the fix to my radar.  #1 did not get fixed before GM, but we have a radar
tracking it (56133558) that was filed by Homebrew.  #3 (dyld) looks to no
longer be an issue in the GM headers.  Can you please confirm?  I just did a
visual check of the file and didn't notice an issue.

In the future, please feel free to poke me directly via email when you file a
report like this as I will definitely work to get a fix into the earliest
possible release.  These types of issues are a personal pet peeve of mine ;)

[Bug target/90835] Incompatibilities with macOS 10.15 headers

[John.W.Marshall at glasgow dot ac.uk]

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

--- Comment #14 from John Marshall  ---
[In reply to Jeremy Huddleston Sequoia in comment #12]

In the future, please file radars for these problems and ping me directly if
you want.  Issues in macOS headers don't get fixed if we don't know about them,
and I'd prefer to fix the SDK itself than have GCC use fixup hacks.
[snip]
The __OSX_AVAILABLE_STARTING issue still exists in the GM SDK as it was never
reported to Apple AFAIK.  I've filed a radar now to track it:
.

Thanks for the advice. I reported this to Apple in early June (FB6125120), as
noted in comment #4 above. Looking at it in
feedbackassistant.apple.com today, there is
no real indication anyone at Apple has ever read it. So that's unfortunate.

John

[Bug target/90835] Incompatibilities with macOS 10.15 headers

[jeremyhu at macports dot org]

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

--- Comment #13 from Jeremy Huddleston Sequoia  
---
Also note that  also already does the following:

/*
 * Compatibility with compilers and environments that don't support compiler
 * feature checking function-like macros.
 */
#ifndef __has_builtin
#define __has_builtin(x) 0
#endif
#ifndef __has_include
#define __has_include(x) 0
#endif
#ifndef __has_feature
#define __has_feature(x) 0
#endif
#ifndef __has_attribute
#define __has_attribute(x) 0
#endif
#ifndef __has_extension
#define __has_extension(x) 0
#endif

which might be why you see the problematic behavior sometimes but not always,
depending on header include order =/

[Bug target/90835] Incompatibilities with macOS 10.15 headers

[jeremyhu at macports dot org]

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

Jeremy Huddleston Sequoia  changed:

   What|Removed |Added

 CC||jeremyhu at macports dot org

--- Comment #12 from Jeremy Huddleston Sequoia  
---
> perhaps Apple decided to ignore the report?
No.  We fix these issues when they're reported.

In the future, please file radars for these problems and ping me directly if
you want.  Issues in macOS headers don't get fixed if we don't know about them,
and I'd prefer to fix the SDK itself than have GCC use fixup hacks.

The __has_builtin() usage in Availability.h and TargetConditionals.h was
reported to me by Homebrew shortly after beta 1 and we fixed it internally
within a couple hours, landing it in a future beta.  We very much care about
the quality of the SDK, and if you run into issues, I'm more than happy to
champion them myself to avoid hacks like this in toolchains.

The __OSX_AVAILABLE_STARTING issue still exists in the GM SDK as it was never
reported to Apple AFAIK.  I've filed a radar now to track it:
.

>  unconditionally uses the availability attribute.

I'm not seeing that in the shipped SDK.  Perhaps it was filed by someone and
addressed.  If it's still an issue that I'm just not seeing, please file a
radar.

[Bug target/90835] Incompatibilities with macOS 10.15 headers

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-23
 Ever confirmed|0   |1

--- Comment #11 from Iain Sandoe  ---
current trunk builds fine on 10.14 with the 10.14 SDK in the 11.0 command line
tools.

It looks like the 10.15 SDK will need a patch to work around our missing
__has_() e.g. comment #5.  I'm testing that (on 10.14) and will apply it as
band-aid if the results are satisfactory.

[Bug target/90835] Incompatibilities with macOS 10.15 headers

[howarth.at.gcc at gmail dot com]

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

--- Comment #10 from Jack Howarth  ---
FYI, Xcode 11 is now released and being pushed, via App Store updates, to
Mojave users. So the gcc bootstrap is now officially broken on Mojave and
Catalina.

[Bug target/90835] Incompatibilities with macOS 10.15 headers

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #9 from Eric Gallager  ---
(In reply to Jack Howarth from comment #8)
> Jeremy's comment on this issue was...
> 
> "Although frankly, it is well past time that GCC add support for these
> macros and attributes if they want to actually consider darwin a supported
> platform."
> 
> so I suspect upstream may expect FSF gcc to finally support these macros at
> this late date.

This would be a lot easier if Apple would let their employees contribute to
GPL3+-licensed projects. It's kind of unfair of them to keep introducing new
non-standard language features while expecting everyone else to add support for
them without actually putting in the work to see that support added.

[Bug target/90835] Incompatibilities with macOS 10.15 headers

[howarth.at.gcc at gmail dot com]

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

Jack Howarth  changed:

   What|Removed |Added

 CC||howarth.at.gcc at gmail dot com

--- Comment #8 from Jack Howarth  ---
Jeremy's comment on this issue was...

"Although frankly, it is well past time that GCC add support for these macros
and attributes if they want to actually consider darwin a supported platform."

so I suspect upstream may expect FSF gcc to finally support these macros at
this late date.

[Bug target/90835] Incompatibilities with macOS 10.15 headers

[iains at gcc dot gnu.org]

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

--- Comment #7 from Iain Sandoe  ---
(In reply to John Marshall from comment #6)
> > let's not speculate ... could you (and/or Rainer) try this (untested) patch 
> > and
> > see how far it gets you?
> 
> Fails in approximately the same place as without:
> 
> ../../gcc/configure --disable-nls --disable-multilib
> --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
> --enable-languages=c,c++
> Make

> ^~~~
> 
> I.e. it got no definition of __AVAILABILITY_INTERNAL__MAC_10_10.

OK. So we're stuck with either (hopefully) a fix in the released version or
another fix includes.

Let's hope for the former - there's no point in committing fixincludes patches
for something unreleased, but I suppose someone could cook up/propose the
minimum needed.

(It seems that the one for 10.13/14 SDKs needs applying anyway.)

[Bug target/90835] Incompatibilities with macOS 10.15 headers

[John.W.Marshall at glasgow dot ac.uk]

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

--- Comment #6 from John Marshall  ---
> let's not speculate ... could you (and/or Rainer) try this (untested) patch 
> and
> see how far it gets you?

Fails in approximately the same place as without:

../../gcc/configure --disable-nls --disable-multilib
--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
--enable-languages=c,c++
Make
[...]
/Users/johnm/thirdparty/build/gcc-perbrew-iains/./gcc/xgcc
-B/Users/johnm/thirdparty/build/gcc-perbrew-iains/./gcc/
-B/usr/local/x86_64-apple-darwin18.6.0/bin/
-B/usr/local/x86_64-apple-darwin18.6.0/lib/ -isystem
/usr/local/x86_64-apple-darwin18.6.0/include -isystem
/usr/local/x86_64-apple-darwin18.6.0/sys-include   -fno-checking -g -O2 -O2  -g
-O2 -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
-Wno-error=format-diag -Wno-format -Wstrict-prototypes -Wmissing-prototypes
-Wno-error=format-diag -Wold-style-definition  -isystem ./include  
-mmacosx-version-min=10.5 -pipe -fno-common -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector   -mmacosx-version-min=10.5 -pipe -fno-common -I. -I.
-I../.././gcc -I../../../../gcc/libgcc -I../../../../gcc/libgcc/.
-I../../../../gcc/libgcc/../gcc -I../../../../gcc/libgcc/../include 
-DHAVE_CC_TLS -DUSE_EMUTLS -o _muldi3_s.o -MT _muldi3_s.o -MD -MP -MF
_muldi3_s.dep -DSHARED -DL_muldi3 -c ../../../../gcc/libgcc/libgcc2.c
In file included from
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/_stdio.h:69,
from
/Users/johnm/thirdparty/build/gcc-perbrew-iains/gcc/include-fixed/stdio.h:78,
from ../../../../gcc/libgcc/../gcc/tsystem.h:87,
from ../../../../gcc/libgcc/libgcc2.c:27:
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/stdio.h: In
function 'renameat':
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/stdio.h:39:56:
error: expected declaration specifiers before
'__AVAILABILITY_INTERNAL__MAC_10_10'
39 | int renameat(int, const char *, int, const char *)
__OSX_AVAILABLE_STARTING(__MAC_10_10, __IPHONE_8_0);
|   
^~~~

I.e. it got no definition of __AVAILABILITY_INTERNAL__MAC_10_10.

[Bug target/90835] Incompatibilities with macOS 10.15 headers

[iains at gcc dot gnu.org]

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

--- Comment #5 from Iain Sandoe  ---
(In reply to John Marshall from comment #4)
> (In reply to comment #3)
> > > --- Comment #2 from Iain Sandoe  ---
> > > * for the other things, if it's a beta, then perhaps there's some chance 
> > > it
> > > will be fixed before issue.
> > 
> > Right: I believe I got at least one such bug fixed during 10.14 Beta.
> 
> FWIW I've reported the AvailabilityInternal.h part to Apple (as FB6125120),
> though I'm just some rando on the internet so they probably haven't even
> read it yet. With a few dozen more duplicate reports they might look into
> it... :-)  (See https://twitter.com/jomarnz/status/1136275996515155969 and
> thread.)

thanks, AFAIU they are somewhat driven by radars for fixing things - so it's
worth doing.

> 
> > > * we 
> > >   - unconditionally define __has_xx(x) 0 in Darwin's builtin defines
> > 
> > That's most likely the easiest way out.
> 
> I don't think that'll help the AvailabityInternal.h problem as presumably
> these things are already decaying to 0, leading to a path through
> AvailabityInternal.h that never defines __AVAILABILITY_INTERNAL__MAC_10_14
> et al. So predefining them to 0 will lead to the same path, no?

let's not speculate ... could you (and/or Rainer) try this (untested) patch and
see how far it gets you?

(I don't expect it to solve all problems, but maybe some - it also might create
some by introducing the false assumption that the reports about
builtins/extensions are valid).

diff --git a/gcc/config/darwin-c.c b/gcc/config/darwin-c.c
index aa5d2f2..9440b30 100644
--- a/gcc/config/darwin-c.c
+++ b/gcc/config/darwin-c.c
@@ -731,6 +731,13 @@ darwin_cpp_builtins (cpp_reader *pfile)
   builtin_define_with_value ("__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__",
 macosx_version_as_macro(), false);

+  /* Until we implement __has-builtin, __has_feature, __has_extension it's
+ better to jam them to 0 than to fight the cases where system headers
+ have not been tested with GCC.  */
+  builtin_define_with_value ("__has_builtin(X)", "0", false);
+  builtin_define_with_value ("__has_feature(X)", "0", false);
+  builtin_define_with_value ("__has_extension(X)", "0", false);
+
   /* Since we do not (at 4.6) support ObjC gc for the NeXT runtime, the
  following will cause a syntax error if one tries to compile gc attributed
  items.  However, without this, NeXT system headers cannot be parsed 

> >>   - implement __has_x() .. which would be nicer, but not sure who has 
> >> time
> >> to do it .. 
> 
> I've been feeling some temptation to implement
> __attribute__(availability(...)) as a no-op that just ignores its arguments.
> It would be preferable for Apple to put the fallback definitions back into
> their header, but failing that capitulating to __availability__ seems
> least-worst.

I'm not in favour of defining that to "do nothing" (actually a "do nothing"
attribute patch is only a few lines) - I suspect defining it to "do nothing"
would open a different can of worms - at least the absence of something is a
known state to Apple - and reasonably can be made to operate conservatively.

I have an implementation for __attribute__(__unavailable__) on my gcc-5 branch,
it needs bringing forward (and get accepted onto trunk) - at that point, it's
probably not too hard to implement the availability attribute.

[Bug target/90835] Incompatibilities with macOS 10.15 headers

[John.W.Marshall at glasgow dot ac.uk]

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

John Marshall  changed:

   What|Removed |Added

 CC||John.W.Marshall at glasgow dot 
ac.
   ||uk

--- Comment #4 from John Marshall  ---
(In reply to comment #3)
> > --- Comment #2 from Iain Sandoe  ---
> > * for the other things, if it's a beta, then perhaps there's some chance it
> > will be fixed before issue.
> 
> Right: I believe I got at least one such bug fixed during 10.14 Beta.

FWIW I've reported the AvailabilityInternal.h part to Apple (as FB6125120),
though I'm just some rando on the internet so they probably haven't even read
it yet. With a few dozen more duplicate reports they might look into it... :-) 
(See https://twitter.com/jomarnz/status/1136275996515155969 and thread.)

> > * we 
> >   - unconditionally define __has_xx(x) 0 in Darwin's builtin defines
> 
> That's most likely the easiest way out.

I don't think that'll help the AvailabityInternal.h problem as presumably these
things are already decaying to 0, leading to a path through
AvailabityInternal.h that never defines __AVAILABILITY_INTERNAL__MAC_10_14 et
al. So predefining them to 0 will lead to the same path, no?

>>   - implement __has_x() .. which would be nicer, but not sure who has 
>> time
>> to do it .. 

I've been feeling some temptation to implement __attribute__(availability(...))
as a no-op that just ignores its arguments. It would be preferable for Apple to
put the fallback definitions back into their header, but failing that
capitulating to __availability__ seems least-worst.

(That'd probably be big enough that I'd have to finally get myself
copyright-assigned first.)

[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 #3 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #2 from Iain Sandoe  ---
> does the existing availability hack work [below]?

It won't: one major problem was the use of __OSX_AVAILABLE and
__OSX_AVAILABLE_STARTING throughout OS headers, but without a fallback
definition in  if the compiler used doesn't support
__has_builtin and the availability attribute.

> * for the other things, if it's a beta, then perhaps there's some chance it
> will be fixed before issue.

Right: I believe I got at least one such bug fixed during 10.14 Beta.

> * we 
>   - unconditionally define __has_xx(x) 0 in Darwin's builtin defines

That's most likely the easiest way out.

>   - make more fix include hacks..

While possible, it has all the known problems: fixed headers get out of
sync with newer headers from Xcode updates or fixes won't longer apply
because the select patterns don't match any longer.

>   - implement __has_x() .. which would be nicer, but not sure who has time
> to do it .. 

Exactly: I suspect there are more pressing issues with the macOS port
than this one ;-)

[Bug target/90835] Incompatibilities with macOS 10.15 headers

[iains at gcc dot gnu.org]

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

--- Comment #2 from Iain Sandoe  ---
does the existing availability hack work [below]?

*if the person who originally put it into pr83531 doesn't post it soon - I plan
to apply it anyway - having re-tested with 10.13/10.14(SDK2)

* for the other things, if it's a beta, then perhaps there's some chance it
will be fixed before issue.

* we 
  - unconditionally define __has_xx(x) 0 in Darwin's builtin defines
  - make more fix include hacks..
  - implement __has_x() .. which would be nicer, but not sure who has time
to do it .. 

diff --git a/fixincludes/inclhack.def b/fixincludes/inclhack.def
index ef23e489e..d9b96faa9 100644
--- a/fixincludes/inclhack.def
+++ b/fixincludes/inclhack.def
@@ -194,6 +194,33 @@ fix = {
_EndOfHeader_;
 };

+/*
+ *  SDKs for 10.13 and 10.14 omit the definitions for API_AVAILABLE where
+ *  __attribute__((availability)) is not supported.
+ */
+fix = {
+hackname  = darwin_api_availability;
+mach  = "*-*-darwin*";
+files = os/availability.h;
+bypass= "__IPHONE_OS_VERSION_MIN_REQUIRED";
+select=
+" *#define __API_AVAILABLE.*\n"
+" *#define __API_DEPRECATED.*\n"
+" *#define __API_DEPRECATED_WITH_REPLACEMENT.*\n"
+" *#define __API_UNAVAILABLE.*\n";
+c_fix = format;
+c_fix_arg =
+"#define API_AVAILABLE(...)\n"
+"#define API_DEPRECATED(...)\n"
+"#define API_DEPRECATED_WITH_REPLACEMENT(...)\n"
+"#define API_UNAVAILABLE(...)\n";
+test_text =
+"#define __API_AVAILABLE(...)\n"
+"#define __API_DEPRECATED(...)\n"
+"#define __API_DEPRECATED_WITH_REPLACEMENT(...)\n"
+"#define __API_UNAVAILABLE(...)\n";
+};
+
 /*
  *  This fixes __FD_ZERO bug for linux 2.x.y (x <= 2 && y <= some n)
  */
diff --git a/fixincludes/tests/base/os/availability.h
b/fixincludes/tests/base/os/availability.h
new file mode 100644
index 0..e8696b14a
--- /dev/null
+++ b/fixincludes/tests/base/os/availability.h
@@ -0,0 +1,18 @@
+/*  DO NOT EDIT THIS FILE.
+
+It has been auto-edited by fixincludes from:
+
+   "fixinc/tests/inc/os/availability.h"
+
+This had to be done to correct non-standard usages in the
+original, manufacturer supplied header file.  */
+
+
+
+#if defined( DARWIN_API_AVAILABILITY_CHECK )
+#define API_AVAILABLE(...)
+#define API_DEPRECATED(...)
+#define API_DEPRECATED_WITH_REPLACEMENT(...)
+#define API_UNAVAILABLE(...)
+
+#endif  /* DARWIN_API_AVAILABILITY_CHECK */

[Bug target/90835] Incompatibilities with macOS 10.15 headers

[ro at gcc dot gnu.org]

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

--- Comment #1 from Rainer Orth  ---
Created attachment 46480
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46480=edit
macOS 10.15 header patches to allow bootstrap to complete