gcc 12 to 14 updates with libsanitizer and Distribution=13.0, 14.0, 15.0 variants - #1080
gcc 12 to 14 updates with libsanitizer and Distribution=13.0, 14.0, 15.0 variants#1080dhomeier wants to merge 9 commits into
Conversation
dhomeier
added
new package
| Version: 12.3.0 | ||
| Revision: 1 | ||
| Type: gccver (12) | ||
| Distribution: 13.0 |
There was a problem hiding this comment.
Perhaps also add 14.0 here?
There was a problem hiding this comment.
Fink's naming scheme only allows for a single Distribution in a %v-Dist.info named file afaict, so this needs additional info files (added in next commit) – but a less prolific solution would be much preferred!
| Source: mirror:gnu:gcc/gcc-%v/gcc-%v.tar.xz | ||
| Source-Checksum: SHA256(949a5d4f99e786421a93b532b22ffab5578de7321369975b91aec97adfda8c3b) | ||
| PatchFile: %n.patch | ||
| PatchFile-MD5: 7d533489637df18650d997f3139c5772 |
There was a problem hiding this comment.
Incorrect MD5 for patch - should be e245cee9fa6aa2fd5298d7712358e8e1
There was a problem hiding this comment.
PatchFile-MD5's still don't seem to match in gcc12-13.0.info, and between gcc13.info, gcc13-13.0.info, and gcc13-14.0.info
4051225 to
de95d59
Compare
|
I have now tried the following combinations:
Both compile and appear to work as intended (at least to the point where fftw3 and cfitsio build). There is still a mistake in the PatchFile-MD5 field in gcc12-13.0.info, and mismatches in this field between the different gcc13 variants (I'm not sure which is correct - I haven't got around to building GCC13 yet, and probably won't for a few days). Thank you for submitting this PR! |
de95d59 to
4417407
Compare
|
|
|
I tried testing this PR on Big Sur with Xcode 13, but got these results: |
|
Does this PR make PR #928 obsolete? |
|
Yes, I think everything relevant especially for the first gcc11 and gcc12 ports has already been cherry-picked, and the rest must be outdated by now. |
|
On Sonoma with Xcode 15.1 the gcc12 build fails with various, generally random internal compiler errors after Stage 3; status with Xcode 15 on Ventura is unclear – might be best to pull the Distribution 12.0/13.0 versions. Update: on High Sierra gcc 13.2 fails to build on a missing header in stage 3: So this might be a blocker for updating past gcc11 on older systems. |
|
I just compiled gcc11, and gcc12 with these package definitions on the following systems |
|
Thanks for confirming the build on Ventura! |
|
I have issues with blas on arm64. It crashes when executing tests. Haven't examined if that is a blas or with gcc. |
|
Anything related to #908 (comment)? |
Do you mean related to it being merged, or related to the problem that it was meant to address? |
|
I've tried building GCC 14.2 on an Intel processor, running MacOS 14.7.1 with command-line tools 16.1. And unfortunately it fails with a similar assembly issue to that mentioned above, while building libgcc: |
|
Building gcc14 still fails with the same issue as before on an Intel processor, MacOS Sonoma 14.7.4 / Darwin 23.6.0, Xcode command-line tools 16.2. |
Those look similar to the errors in Is there any working gcc on 14.x and x86_64 then? For arm64 with Xcode 16 there definitely is none at this point, so it would be good to get this unblocked. I could remove the gcc14-14.0 distribution then; if so, should I do it for Intel only (apparently we have an |
f5c471e to
cf99a0f
Compare
|
I have submitted the issue with Intel processors as iains/gcc-14-branch#19. I have now upgraded this machine to MacOS 15.3.2, but see the same errors as before. |
|
Following advice from @iains (on the thread linked above), it looks like the issue on Intel processors was related to the presence of GNU's objdump, as installed by Fink's objtools, on the path causing problems in the detection of clang's assembly features. This can be overridden by adding |
|
I can also confirm that GCC 13.3 builds on MacOS 15.4 on Intel with the same fix applied. |
|
It would be great if the change suggested above could be added, so this can be merged soon! |
|
The general version-bump of gcc12 seems fine. I see that it's only for up through OSX 13.0. Is the 13.0 trick also portable to 14.0 and 15.0? Adding new gccXX with whatever tricks are needed per platform seems fine. I see that gcc14 is only for OSX 13.0 and above. Is it not buildable on older OSX? We can obviously take what we have now and then spread it to those missing platforms as soon as someone figures out how, just want to make sure I understand what we have now. |
|
Answering one of my own questions... gcc14 FTBFS on 10.13 with a clang crash and So at least for now, gcc13 will be the highest gccXX that is available on all OSX. |
Not quite sure what you are doing here. I test on x86_64-darwin17..24 (macOS10.13..macOS15) and i686-darwin9 and 17 (using available Xcode CLT installs). I sometimes test on 10.12 and earlier (but limited on what test hardware I have available) .. there's no reason to expect that there would be any build issues on versions >= 10.5. All of these platforms work with unpatched GCC 12.5, GCC-13.4, GCC-15.2 (soon to be released) and gcc-16 development. See, for example, the test results for 15.2 release candidate and for this weekend's trunk (gcc-16) You need a patched branch to build arm64 - but for x86_64/i686 it should "just work"... so you should look for fallout from some other component. |
|
I'm OS X 10.13 on an x86_64 Mac. I took the gcc14.info and adjusted Distribution to include 10.13, so that .info has all the patch/script magic that is used. Here's the fail: but it seemed pointless to report something to them on a long-unsupported OS X. But in particular there is no .crash file in the Logs/DiagnosticReports in my homedir. The run script is: The associated .c is about 7MB if you want it. |
|
Apologies, but I am not able to analyse or support the non-standard builds of the distribution(s) - simply not enough time :) ... the point I was making is that GCC is regularly tested on (at least) versions of macOS back to 10.13 (using the "standard" Apple-released Xcode CLTs for the assembler/linker/dsymutil) - so if it is not working in your configuration, the problem may lies with some replacement for those tools (or, perhaps some build-time tool).. It should be possible to have GCC up to current trunk working there. |
|
Thanks for dropping by, and continuing to support/test your mainline on our old platforms. I'm just testing the fink package, which obviously has a lot of patch and I don't know anything about that myself. |
|
Using patches from cf99a0f:
On 13.7.1/x86_64,
So looks like |
|
I've edited the top comment to add what I think are the current status of tested gcc versions from here against distritbutions. So far the only fail I'm sure of is gcc14/10.13 via @dmacks and the x86_64 problems on 15.x with objtools via @PovlAbrahamsen (which has a workaround). If you know a combination either passes or fails, please add so it's easier to know the situation |
For the record, I am probably no longer able to test things on 10.13. |
|
Sorry, should have posted here instead of PR#1301 Here is error for building gcc12 on X86_64 |
|
Are you building from upstream - or from my development branches? Arm64 is not expected to work from upstream - but x86_64 does (although without some of the clang-compatibility changes that are on the development branches). =====
xcode 26.2 has been working fine. |
|
@iains I am building from upstream master for both systems. I thought I had something local that worked for gcc12 but that was macOS 15 or so. |
|
OK. upstream cannot work for arm64 yet (I still need to upstream the devt. patches). Homebrew (cited above) take patch-sets from my devt. branch(es). However, x86_64 should be OK with upstream - modulo any patches added to later GCC versions for Tahoe (there are def. some because of the change in mapping from darwinXX to macOSYY). I will try to look into what's needed in the next week or so - and also look into the issues with Xcode 26.5 |
|
I have gcc-12.5.0 fully built on Tahoe/ARM, using a combination of homebrew patches, upstream patches, and fink packaging controls. But it has an inconsistency about whether it thinks it is "arm64" vs "aarch64". |
This was decided by the config. folks before I had any chance to make input (and by that time it was too late to have the option to name triples arm64-apple-darwinNN)
however, since we need to interact with Apple's tools and LLVM |
|
Here we go: e9682a9 libsanitizer is still disabled on arm, which is the only sandbox I have at the moment., as it already was on our gcc12 packaging. I have no idea if not having that is a blocker, or if it's easily fixable, or if we should just go without it for now to at least get something viable pushed. Please test on x86_64 and lower OS. [sorry for the transient ticket closure!] |
7 participants
Counterpart of #1033 for gcc versions 12.3 and 13.2, with patches from the gcc arm64 team copied from Homebrew.
Adding the same experimental build of AddressSanitizer and ThreadSanitizer tools as for gcc11 – however libasan in particular is untested with gcc13.
Tested on 13.4 and 12.7 arm64 and x86_64/Rosetta, and on 10.14.6 x86_64; still needs testing on latest 13.x arm64 with Xcode 15.
gcc12
PASS 10.14.6/x86_64 @dhomeier @nieder
PASS 13.7/x86_64 @nieder
FAIL/PASS 15.4/x86_64 with
with-build-time-toolscomment @PovlAbrahamsenPASS arm64 @dhomeier
gcc13
PASS 10.14.6/x86_64 @dhomeier @nieder
PASS arm64 @dhomeir
gcc14
FAIL 10.13 comment @dmacks
PASS 10.14.6/x86_64 @dhomeier @nieder
FAIL/PASS 15.4/x86_64 with
with-build-time-toolscomment @PovlAbrahamsenPASS arm64 @dhomeir