Once the issues from PR target/90834 are worked around or fixed, there remain a couple of bugs in the macOS 10.15/Xcode 11 headers that make them incompatible with gcc, breaking the gcc build. While I mean to report them to Apple, I'm reporting them here either for others who want to try the same build or in case they aren't fixed upstream in time. * <Availability.h> lacks fallback definitions of __OSX_AVAILABLE_STARTING and friends if the availability attribute isn't supported (as in gcc, unlike clang). * <AvailabilityInternal.h> unconditionally uses __has_builtin. Besides, the fixes for lack of the availability attribute in __API_[ADU] are still needed. Probably nobody reported them upstream, or perhaps Apple decided to ignore the report? * <mach-o/dyld.h> unconditionally uses the availability attribute. Just commenting those uses as I've done is a hack; probably there another weird macro in <Availability*.h> that's cleaner here. * <TargetConditionals.h> unconditionally uses __has_builtin. With those patches, I managed to complete a mainline bootstrap on Darwin 19; make check still running.
Created attachment 46480 [details] macOS 10.15 header patches to allow bootstrap to complete
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_xxxxxx(x) 0 in Darwin's builtin defines - make more fix include hacks.. - implement __has_xxxxx() .. 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 000000000..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 */
> --- Comment #2 from Iain Sandoe <iains at gcc dot gnu.org> --- > 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 <Availability.h> 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_xxxxxx(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_xxxxx() .. 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 ;-)
(In reply to comment #3) > > --- Comment #2 from Iain Sandoe <iains at gcc dot gnu.org> --- > > * 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_xxxxxx(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_xxxxx() .. 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.)
(In reply to John Marshall from comment #4) > (In reply to comment #3) > > > --- Comment #2 from Iain Sandoe <iains at gcc dot gnu.org> --- > > > * 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_xxxxxx(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_xxxxx() .. 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.
> 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.
(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.)
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.
(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.
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.
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_xxxx() e.g. comment #5. I'm testing that (on 10.14) and will apply it as band-aid if the results are satisfactory.
> 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: <rdar://problem/55937005>. > <mach-o/dyld.h> 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.
Also note that <sys/cdefs.h> 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 =/
[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: <rdar://problem/55937005>. 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<http://feedbackassistant.apple.com> today, there is no real indication anyone at Apple has ever read it. So that's unfortunate. John
(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: > <rdar://problem/55937005>. > > 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<http://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 <rdar://problem/51499580>. 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 ;)
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_xxxx => 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).
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!
Downstream MacPorts ticket related to this: https://trac.macports.org/ticket/59113
*** Bug 92445 has been marked as a duplicate of this bug. ***
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.
(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.
(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.
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.
> --- 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*. > If there's no additional information I propose we close this PR after another > week. I guess that's fine. Thanks. Rainer
(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). 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.
> --- 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?
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #26) > > --- 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? I think it has come up in some other bug...
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #26) > > --- Comment #25 from Iain Sandoe <iains at gcc dot gnu.org> --- > > 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)
(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)
(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).
(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.
(In reply to ro@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?
(In reply to Eric Gallager from comment #32) > (In reply to ro@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.
Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627793.html
The master branch has been updated by Eric Gallager <egallager@gcc.gnu.org>: https://gcc.gnu.org/g:9a5d1fceb86a61c9ead380df89ce3c4ba387d2e5 commit r14-3335-g9a5d1fceb86a61c9ead380df89ce3c4ba387d2e5 Author: Eric Gallager <egallager@gcc.gnu.org> 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
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...