Closed ilg-ul closed 2 months ago
iains
commented
2 months ago does the patch I pushed onto the 14.1 branch fix this? https://github.com/iains/gcc-14-branch/commit/75ff8c390327ac693f6a1c40510bc0d35d7a1e22
edit: The availability handling was on trunk and also on the pre-releases - so there was a chance to catch this before we shipped .. but such is life ...
ilg-ul
commented
2 months ago The current Homebrew patch for 14.1 is https://raw.githubusercontent.com/Homebrew/formula-patches/82b5c1cd38826ab67ac7fc498a8fe74376a40f4a/gcc/gcc-14.1.0.diff.
I tried some quick searches and apparently your patch was not included.
If so, @fxcoudert, can you update the Homebrew patch to include it?
iains
commented
2 months ago The current Homebrew patch for 14.1 is https://raw.githubusercontent.com/Homebrew/formula-patches/82b5c1cd38826ab67ac7fc498a8fe74376a40f4a/gcc/gcc-14.1.0.diff.
I tried some quick searches and apparently your patch was not included.
If so, @fxcoudert, can you update the Homebrew patch to include it?
it would be a good idea to check that it fixes your issue first, perhaps?
ilg-ul
commented
2 months ago You mean to append a patch based on https://github.com/iains/gcc-14-branch/commit/75ff8c390327ac693f6a1c40510bc0d35d7a1e22 to the large homebrew patch?
I'll try to do this today and report the result.
iains
commented
2 months ago You mean to append a patch based on 75ff8c3 to the large homebrew patch?
I'll try to do this today and report the result.
yes, that would be great; thanks!
ilg-ul
commented
2 months ago The new macOS Intel binaries built on 10.14 with TARGET 10.13 passed all tests on:
The macOS arm64 binaries built on 11.7 with TARGET 11.0 also passed the tests on GitHub 14.5.
From my point of view I would say that the problem was fixed.
Thank you for your quick reply.
When do you plan to add a gcc-14.1-darwin-r1 tag? Should I wait for more commits, or I can proceed with the release with only this single commit added to Homebrew patches?
iains
commented
2 months ago this is the only report against the r0 so far - so I am happy to tag an r1.
as for whether homebrew / macports etc. update - I cannot comment (but note: @fxcoudert)
ilg-ul
commented
2 months ago so I am happy to tag an r1 ...
ok, please do it, for now I'll assume there will be no further immediate commits and I'll proceed with my 14.1 release.
ilg-ul
commented
2 months ago I think I was a bit too hasty, the arm64 tests were not performed on the GitHub 14.5, but on my own 11.7, and thus passed.
When I tried on GitHub 14.5, some of the tests failed; I'll open a separate issue with the findings.
But this issue related to the availability macros seems fixed.
ilg-ul
commented
2 months ago I'm in the middle of releasing 13.3, using the official archive and the Homebrew patch, I encountered the following error while running the binaries generated for 10.13 on a more recent macOS:
In file included from simple-hello.c:10:
/Users/runner/work/gcc-xpack/gcc-xpack/build/darwin-x64/x86_64-apple-darwin21.6.0/tests/xpack-gcc-13.3.0-1/lib/gcc/x86_64-apple-darwin18.7.0/13.3.0/include-fixed/stdio.h:374:153: error: macro "__API_AVAILABLE6" requires 6 arguments, but only 4 given
374 | FILE *fmemopen(void * __restrict __buf, size_t __size, const char * __restrict __mode) __API_AVAILABLE(macos(10.13), ios(11.0), tvos(11.0), watchos(4.0));
| ^
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/Availability.h:166,
from /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/_stdio.h:69,
from /Users/runner/work/gcc-xpack/gcc-xpack/build/darwin-x64/x86_64-apple-darwin21.6.0/tests/xpack-gcc-13.3.0-1/lib/gcc/x86_64-apple-darwin18.7.0/13.3.0/include-fixed/stdio.h:78:
/Users/runner/work/gcc-xpack/gcc-xpack/build/darwin-x64/x86_64-apple-darwin21.6.0/tests/xpack-gcc-13.3.0-1/lib/gcc/x86_64-apple-darwin18.7.0/13.3.0/include-fixed/AvailabilityInternal.h:52046: note: macro "__API_AVAILABLE6" defined here
52046 | #define __API_AVAILABLE6(x,y,z,t,b,m) __API_A(x) __API_A(y) __API_A(z) __API_A(t) __API_A(b) __API_A(m)
|
/Users/runner/work/gcc-xpack/gcc-xpack/build/darwin-x64/x86_64-apple-darwin21.6.0/tests/xpack-gcc-13.3.0-1/lib/gcc/x86_64-apple-darwin18.7.0/13.3.0/include-fixed/stdio.h: In function 'fmemopen':
/Users/runner/work/gcc-xpack/gcc-xpack/build/darwin-x64/x86_64-apple-darwin21.6.0/tests/xpack-gcc-13.3.0-1/lib/gcc/x86_64-apple-darwin18.7.0/13.3.0/include-fixed/stdio.h:374:88: error: expected declaration specifiers before '__API_AVAILABLE6'
374 | FILE *fmemopen(void * __restrict __buf, size_t __size, const char * __restrict __mode) __API_AVAILABLE(macos(10.13), ios(11.0), tvos(11.0), watchos(4.0));
| ^~~~~~~~~~~~~~~A similar error occurs while testing the arm64 binaries.
Is it possible to back-port the fix to the 13 branch?
fxcoudert
commented
2 months ago The problem is, in my opinion, more general. The "hacking" of headers through GCC's fixincludes is fragile: it means that, for some a limited number of headers, we read the local (patched) copy generated during gcc build instead of read the system one.
The logical consequence is: if you run against a different SDK than you compiled for, you introduce a mismatch of headers. And we won't be able to guarantee that it works for most cases.
The long-term solution is: making GCC able to parse SDK headers better, and Iain has done great work on that.
ilg-ul
commented
2 months ago The long-term solution is: making GCC able to parse SDK headers better, and Iain has done great work on that.
Fully agree, Iain has done a great work, and, on long term, if a more robust solution can be implemented, it is welcome.
On short term, according to my tests, the solution used in the 14 branch seems functional. It would be great to be able to back-port it to the 13 branch too.
iains
commented
2 months ago Is it possible to back-port the fix to the 13 branch?
Yes, I'm testing the back port.
as @fxcoudert says, the long-term solution is to be able to consume the SDKs without changes - or, equivalently, to provide our own SDK.
Neither of these is very easy:
We're making some progress on the first, GCC-14 has two huge steps (handing __has_extension/feature and the availability attribute)... but some things remain and some are quite hard.
ilg-ul
commented
2 months ago Yes, I'm testing the back port.
Any progress on this?
iains
commented
2 months ago Yes, I'm testing the back port.
Any progress on this?
most of the runs are complete - hopefully the remainder will complete tonight.
ilg-ul
commented
2 months ago As discussed in https://github.com/iains/gcc-13-branch/issues/1, the issue was caused by a misunderstanding, the HB patch is not identical to tagged commits here, and the commit fixing the availability macros was not included in HB 13.3.
As I previously reported, I had successful builds of GCC 14 on
In all cases I used the Homebrew patches, and running the extensive tests locally passed.
However, when making the final distribution binaries, I noticed that running the 10.13 binaries on newer machines fails during preprocessing, with errors related to the availability macros.
I isolated a preprocessor command for a simple hello program, and the result is:
If I understand this right, the fixed
stdio.hinvokes the__API_AVAILABLEmacro with 4 arguments, and, after a sequence of headers, the call ends somehow in a more recent header which expects 6 arguments.To make things worse, the same binaries are no longer functional even on a macOS 10.13 but having a different SDK (xcode10.1), for example the one available on Travis CI:
Here the system header expects 3 arguments, and receives 4, plus other errors.
Did I misconfigured my build or is this a compatibility issue with older systems, that was introduced with the recent changes in 14.x?
For the xPack distribution this issue is a show stopper; all other binaries (Windows, Linux Intel, Linux aarch64, Linux arm, macOS arm64) are functional, only the macOS Intel, which is expected to run on everything from macOS 10.13 up, is failing.
Any suggestions?