gcc 12.2 build with patches for M1 #928

dhomeier · 2022-11-11T00:45:36Z

This PR is building the current gcc 12.2 suite (including gfortran) for arm[arm64] on Monterey (tested on 12.5/12.6) using the patches from https://github.com/iains/gcc-12-branch/releases/tag/gcc-12.2-darwin-r0 as collected in the Homebrew patch https://github.com/Homebrew/formula-patches/blob/master/gcc/gcc-12.2-arm.diff .
Since there is no settled architecture setup for Apple Silicon or even an official install path on macOS 11 or later, this is necessarily experimental, but tested on 12.5/12.6 both for arm64 and x86_64 (under Rosetta) and on 10.14 with the same patches. Note that I have omitted the original PatchFiles0-3 here as gcc built on all archs without them, but if they are still required for older systems, it should still be possible to include them.
Equivalent patches also exist for gcc 11.3, but the arm64 patches are most likely to make it into the 12.x release (the earliest), so it's probably better to build on this (and upgrade all the packages just moved to gcc11 to gcc12).

The other commits include ports or upstream updates for dependencies that don't build on arm in the current version.

nieder · 2022-11-15T11:39:10Z

Game for moving things from gcc11 to gcc12, but rmods will be difficult since r-base itself hardcodes the used gcc version and that then propagates to the rmods.

For this:

apfs patch note was added to DescPackaging, but that patch was removed (in fact patch is already commented out and removed from git).
please bump %r

nieder · 2022-11-15T11:43:42Z

Also, why did a bunch of other pkgs get added here (like glib2)? And help2man is now using the token $m instead of the expected %m. Will %m need to be arm64 on M# cpus instead of just arm?

dhomeier · 2022-11-22T22:17:38Z

Also, why did a bunch of other pkgs get added here (like glib2)?

Those are all [B]Deps that require patching, or in some cases, updates to a newer upstream, to build on arm64.
glib2 is an exception, as I had some problems building the current version with the pkgconf from #923, but eventually got the build for 2.22.4 to work as well. There are some other package updates that depend on newer versions, but no immediate dependencies of gcc12, and the tests for 2.22.4-9 are hanging (with 2 failing out of ~48, vs. for 2.59 2 out of some 3800 failing). But 2.59 also requires a python3 to build, so I had to dist-restrict it to Catalina and above, keeping the original package for older systems. This could all go into a different PR of course.

And help2man is now using the token $m instead of the expected %m. Will %m need to be arm64 on M# cpus instead of just arm?

Yes, arch only accepts arm64, so it either needs to be patched this way (applies to a lot of perl packages), or %m had to be set to arm64. That could be done by checking uname -m prior to -p in bootstrap, but I'm not sure that will lead anywhere. I got dpkg 1.19.7 to accept this by patching its config.sub, but so far bootstrapping then fails in phase 3 with

/opt/sw4/bootstrap/bin/dpkg -i /opt/sw4/fink/dists/stable/main/binary-darwin-arm64/base/base-files_1.9.19-1_darwin-arm64.deb
./
./control
./md5sums
./package.info
./postinst
dpkg: error processing archive /opt/sw4/fink/dists/stable/main/binary-darwin-arm64/base/base-files_1.9.19-1_darwin-arm64.deb (--install):
package architecture (darwin-arm64) does not match system (darwin-arm)

Even if the 'system' architecture could be fixed next, I am not sure if this is the preferable choice, as there seem to be just as many packages that can handle arm, but not arm64.

Pushed 11.3 as well, but I have not tried to build any r-base so far.

TheSin- · 2022-11-22T22:22:13Z

I'll by fixing my branch for M processors soonish, I have an M1 with macOS 13 on it ready, just need time

nieder · 2022-11-27T11:23:33Z

I cherry picked the gcc11/12 specific commits since they're the lowest packages and this way they don't wait on the other stuff being completed.

dmacks · 2022-12-21T07:56:52Z

I cherry picked the gcc11/12 specific commits since they're the lowest packages and this way they don't wait on the other stuff being completed.

Latest gcc11 update changes some dyld linking among lib/lib*.dylib in a way that breaks previously-compiled binaries at runtime ([Fink-users] dyld: Library not loaded: @rpath/libgcc_s.1.1.dylib). For example, whereas gcc11-11.3.0-1 gave me:

/sw/lib/gcc11/lib/libgcc_s.1.1.dylib:
	/sw/lib/gcc11/lib/libgcc_s.1.1.dylib (compatibility version 1.0.0, current version 1.1.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.50.4)
/sw/lib/gcc11/lib/libgcc_s.1.dylib:
	/sw/lib/gcc11/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
	/sw/lib/gcc11/lib/libgcc_s.1.1.dylib (compatibility version 1.0.0, current version 1.1.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.50.4)

gcc11-11.3.0-2 gave me:

/sw/lib/gcc11/lib/libgcc_s.1.1.dylib:
	/sw/lib/gcc11/lib/libgcc_s.1.1.dylib (compatibility version 1.0.0, current version 1.1.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.50.4)
/sw/lib/gcc11/lib/libgcc_s.1.dylib:
	/sw/lib/gcc11/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.1.0)
	@rpath/libgcc_s.1.1.dylib (compatibility version 1.0.0, current version 1.1.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.50.4)

dhomeier · 2022-12-23T01:49:58Z

Latest gcc11 update changes some dyld linking among lib/lib*.dylib in a way that breaks previously-compiled binaries at runtime ([Fink-users] dyld: Library not loaded: @rpath/libgcc_s.1.1.dylib). For example, whereas gcc11-11.3.0-1 gave me:

Yes, those are the iains-gcc patches now setting @rpath in most dylibs, which seems necessary to get it to build on arm64, but did already break in other tests, so I manually fixed the paths in InstallScript.
However x86_64 in addition builds libgcc_s.1.dylib (which does not exist on arm64) with its extra reference to libgcc_s.1.1.dylib that I had overlooked. Strangely libgcc_s.1.1.dylib itself does not come with @rpath...
This could be fixed with install_name_tool, too; or all the gcc12-arm patches could just be applied conditionally for %m == 'arm' only. But that would maybe break the idea of providing identical gcc builds as far as possible (and on arm64 the cherry-picked packages will not build anyway without the extra dependency updates here).

Also I had added the patched gcc11 version due to the difficulties getting r-base to use gcc12; however so far I was unable to build 11.3 on 13.1 (neither for x86_64/Rosetta not arm64). So perhaps we should just stick with gcc12 now.

dhomeier · 2022-12-26T14:48:58Z

Hopefully fixed all relative dylib paths now, and this should resolve #934 as well.
/usr/bin/install-info has also been removed on Ventura, thus switching to Fink's; this could of course be made conditional on the system version.

…ld on Ventura

nieder · 2022-12-27T16:14:55Z

The @rpath fix is not right:

$ otool -L /opt/sw/lib/gcc12/lib/libgcc_s.1.dylib 
/opt/sw/lib/gcc12/lib/libgcc_s.1.dylib:
	/opt/sw/lib/gcc12/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.1.0)
	/opt/sw/lib/libgcc_s.1.1.dylib (compatibility version 1.0.0, current version 1.1.0, reexport)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.0.0)
$ file /opt/sw/lib/libgcc_s.1.1.dylib
/opt/sw/lib/libgcc_s.1.1.dylib: cannot open `/opt/sw/lib/libgcc_s.1.1.dylib' (No such file or directory)

Modify the install_name_tool -change call to this?

		install_name_tool -change @rpath/libgcc_s.1.1.dylib %p/lib/gcc%type_num[gccver]/lib/libgcc_s.1.1.dylib \
				-change @rpath/libstdc++.6.dylib %p/lib/gcc%type_num[gccver]/lib/libstdc++.6.dylib \
				-change @rpath/libquadmath.0.dylib %p/lib/gcc%type_num[gccver]/lib/libquadmath.0.dylib $dylib

dhomeier · 2022-12-28T11:49:13Z

Doh, should have sticked to the wildcard expression!
I've only tested the fix on arm (takes half a day to build under Rosetta), but running an OpenBLAS build now to practice-test the compiler.

nieder · 2022-12-31T11:24:18Z

Pushed the new gccNN changes for rpath. That should deal with #934.

nieder · 2022-12-31T12:31:04Z

libffi bumped SOVERSION after our 3.2.1, so we'll need a new libN for it (libffi8). We can't just bump the version and change the library name like in 33d1a6e. Working on a new .info for that now.

ETA: pushed the new libffi8 package. Will we have to update the gcc11/12 packages to use this so that they works cleanly on ARM?

dhomeier · 2023-01-12T19:55:49Z

ETA: pushed the new libffi8 package. Will we have to update the gcc11/12 packages to use this so that they works cleanly on ARM?

Thanks; yes, and whatever else uses libffi6. I've built python310 and ruby26, and for those it's simply a drop-in replacement.

dmacks · 2023-01-13T17:49:18Z

ETA: pushed the new libffi8 package.

I've built python310 and ruby26, and for those it's simply a drop-in replacement.

I pushed those two. Thanks!

nieder · 2023-01-14T11:36:19Z

Is libffi6 then unbuildable on ARM?
Looking at the stuff left using libffi6 (old ruby and llvm), could just mark those as x86_64 only along with libffi6

dhomeier · 2023-01-14T13:49:20Z

Is libffi6 then unbuildable on ARM?

Someone might take a shot at that assembly code, or perhaps try to force compilation without it (there are probably less-optimised C routines for all the same functionality).
But I don't think it is worth spending time on the old version at this point, with many other essential packages needing attention.

dmacks · 2023-01-14T18:25:07Z

Is libffi6 then unbuildable on ARM? Looking at the stuff left using libffi6 (old ruby and llvm), could just mark those as x86_64 only along with libffi6

I see rubyXX back to 24 was migrated to libffi8 whereas ruby 20-23 (and cascaded dependencies on it) were instead tagged NOARM_FFI6. Do those older ruby not migrate cleanly for you? On my 10.13, ruby20 had identical build transcripts with libffi6 vs libffi8. Since I can't help with ARM, I can instead work towards killing off libffi6 altogether.

nieder · 2023-01-14T21:11:28Z

It was mostly a matter of perl <= 23 using crazy old openssl100, so I figured it wasn't worth dragging that along and this gave another reason to stop propagating them.

dhomeier · 2023-01-14T21:35:10Z

On 12.6.1/arm64 the status is

ruby23-25 build against libffi8 without further changes
ruby22 fails on encoding.c:825:2: error: implicit declaration of function 'rb_str_change_terminator_length',
can be fixed by SetCFLAGS: -Wno-implicit-function-declaration
in addition ruby20-22 are failing at the end of the install phase on trying to call rm -a, which is not a supported option

The last 2 don't seem specific to the architecture so should be testable elsewhere.

dmacks · 2023-01-14T23:35:31Z

On 12.6.1/arm64 the status is
* ruby22 fails on encoding.c:825:2: error: implicit declaration of function 'rb_str_change_terminator_length',
can be fixed by SetCFLAGS: -Wno-implicit-function-declaration

Fixed (upstream goof in the tarball)--un-goofed it rather than hiding the message about it. It would have been an error on XCode >= 12ish on all platforms (vs only a warning on older).

sth0 · 2023-01-15T01:05:44Z

(Ambitiously trying to build emacs on M1) Not sure if this is a solved issue on M1 systems or not. I would rather not re-invent things here since it looks like this would happen for a lot of packages. But libid3tags does not recognize the CPU-Manufacturer-OS string that is passed to configure.sub. The error is in running sudo /bin/sh ./config.sub -apple-darwin21.6.0 config.sub: invalid option -apple-darwin21.6.0 Try `config.sub --help' for more information. /bin/sh ./config.sub arm64-apple.darwin21.6.0 results in Invalid configuration `arm64-apple-darwin21.6.0': machine `arm64-apple' not recognized So it seems that in passing this to config.sub the creation of the CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM or the CPU_TYPE-MANUFACTURER-KERNEL-OPERATING_SYSTEM is failing? What routing calls config.sub? Configure I would guess? Any help/pointers would be great.

…

-Scott

dmacks · 2023-01-18T03:17:15Z

I finished migrating the whole dist from libffi6 to libffi8 and turned off the libffi6 headers package. Thanks everyone who worked on test-building!

dhomeier · 2023-01-18T12:05:24Z

The error is in running sudo /bin/sh ./config.sub -apple-darwin21.6.0 config.sub: invalid option -apple-darwin21.6.0 Try config.sub --help' for more information. /bin/sh ./config.sub arm64-apple.darwin21.6.0 results in Invalid configuration arm64-apple-darwin21.6.0': machine `arm64-apple' not recognized

I have patched this with

perl -pi -e 's/(arm-* |)( armbe-*)/$1 arm64-* |$2/' config.sub

ConfigureParams: --build=%m-apple-darwinuname -r|cut -f1 -d.

which let it compile without further changes for 12.6.1.
Will open a PR for those when I am done with the python3 updates.

TheSin- · 2023-01-18T12:38:19Z

you like doing lots of work? Just use UpdateConfigGuess: or UpdateConfigGuessInDirs: instead of patching

dhomeier · 2023-01-18T15:00:37Z

No, just copying solutions from existing packages where alternatives are not documented in https://www.finkproject.org/doc/packaging/format.php; thanks for the pointer (link to usage even more welcome).

dhomeier · 2023-10-18T14:58:57Z

Superseded by #1033, #1080 and others

dhomeier added the enhancement label Nov 11, 2022

dhomeier force-pushed the gcc12-arm branch from 1e6ecdf to d0c7d8d Compare November 11, 2022 18:06

dhomeier added 7 commits December 26, 2022 13:09

gmp5 update to 6.2.1 with arm support

b84befb

libffi6 update to 3.4.2 with arm support

33d1a6e

Patch arch -arm64 for help2man-perl

0c5f076

Add --build flag for expect

f3ed9fc

glib2 update to 2.59.0 with pkgconf build for arm support

7c1046f

Add glib2 2.22.4 as versioned package

dba4fd2

Dist-restrict glib2 2.59.0

8178dd2

dhomeier force-pushed the gcc12-arm branch from c3896d8 to c9c2319 Compare December 26, 2022 14:45

dhomeier mentioned this pull request Dec 26, 2022

gcc11 on 13.x #934

Closed

Fix all rpath names; use Fink install-info and add gcc11 patch to bui…

1e337fe

…ld on Ventura

dhomeier force-pushed the gcc12-arm branch from c9c2319 to 1e337fe Compare December 26, 2022 19:06

Fix lib/gcc%type_num[gccver] install paths

325aece

dmacks added a commit that referenced this pull request Jan 13, 2023

some libffi upgrades (per PR #928)

8674c94

dmacks added a commit that referenced this pull request Jan 14, 2023

ruby23 bump libffi (PR #928), enabling -rb23 for ARM

912b973

nieder added the arm64 Build issues and fixes for Apple Silicon label Sep 8, 2023

dmacks mentioned this pull request Oct 18, 2023

gcc 12 and 13 updates with libsanitizer and Distribution=13.0 variants #1080

Open

dhomeier closed this Oct 18, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

gcc 12.2 build with patches for M1 #928

gcc 12.2 build with patches for M1 #928

dhomeier commented Nov 11, 2022 •

edited

Loading

nieder commented Nov 15, 2022

nieder commented Nov 15, 2022

dhomeier commented Nov 22, 2022

TheSin- commented Nov 22, 2022

nieder commented Nov 27, 2022

dmacks commented Dec 21, 2022

dhomeier commented Dec 23, 2022 •

edited

Loading

dhomeier commented Dec 26, 2022

nieder commented Dec 27, 2022

dhomeier commented Dec 28, 2022

nieder commented Dec 31, 2022

nieder commented Dec 31, 2022 •

edited

Loading

dhomeier commented Jan 12, 2023

dmacks commented Jan 13, 2023 •

edited

Loading

nieder commented Jan 14, 2023

dhomeier commented Jan 14, 2023

dmacks commented Jan 14, 2023

nieder commented Jan 14, 2023

dhomeier commented Jan 14, 2023

dmacks commented Jan 14, 2023 •

edited

Loading

sth0 commented Jan 15, 2023 via email

dmacks commented Jan 18, 2023

dhomeier commented Jan 18, 2023

TheSin- commented Jan 18, 2023

dhomeier commented Jan 18, 2023 •

edited

Loading

dhomeier commented Oct 18, 2023

gcc 12.2 build with patches for M1 #928

gcc 12.2 build with patches for M1 #928

Conversation

dhomeier commented Nov 11, 2022 • edited Loading

nieder commented Nov 15, 2022

nieder commented Nov 15, 2022

dhomeier commented Nov 22, 2022

TheSin- commented Nov 22, 2022

nieder commented Nov 27, 2022

dmacks commented Dec 21, 2022

dhomeier commented Dec 23, 2022 • edited Loading

dhomeier commented Dec 26, 2022

nieder commented Dec 27, 2022

dhomeier commented Dec 28, 2022

nieder commented Dec 31, 2022

nieder commented Dec 31, 2022 • edited Loading

dhomeier commented Jan 12, 2023

dmacks commented Jan 13, 2023 • edited Loading

nieder commented Jan 14, 2023

dhomeier commented Jan 14, 2023

dmacks commented Jan 14, 2023

nieder commented Jan 14, 2023

dhomeier commented Jan 14, 2023

dmacks commented Jan 14, 2023 • edited Loading

sth0 commented Jan 15, 2023 via email

dmacks commented Jan 18, 2023

dhomeier commented Jan 18, 2023

TheSin- commented Jan 18, 2023

dhomeier commented Jan 18, 2023 • edited Loading

dhomeier commented Oct 18, 2023

dhomeier commented Nov 11, 2022 •

edited

Loading

dhomeier commented Dec 23, 2022 •

edited

Loading

nieder commented Dec 31, 2022 •

edited

Loading

dmacks commented Jan 13, 2023 •

edited

Loading

dmacks commented Jan 14, 2023 •

edited

Loading

dhomeier commented Jan 18, 2023 •

edited

Loading