arm-none-eabi-gcc fails to build on M1

[hpux735 (William Dillon)]

port logs

[hpux735 (William Dillon)]

It looks like this might be the upstream bug?

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

[ryandesign (Ryan Carsten Schmidt)]

Yes, that looks like the bug. A common problem with many ports on Big Sur and later. (Any software using libtool and relying on undefined symbols.) Looks like gcc went a slightly different direction with the fix from the one that we usually apply, which is the one I described in the ​upstream libtool bug report which the developers of libtool have yet to acknowledge.

[hpux735 (William Dillon)]

Ah, very interesting. Thanks. Is this something that'll be blocked indefinitely until it's done upstream, or is it something that can be patched in the port files?

[ryandesign (Ryan Carsten Schmidt)]

We should update arm-none-eabi-gcc to the latest version, which is 10.3.0. Maybe that already incorporates the fix. If not, or if updating is too difficult, we can apply a patch.

Note that "we" means any interested volunteer. This port has no maintainer.

[hpux735 (William Dillon)]

Ok, I can give it a shot. Just so long as you don't mind me asking questions on this bug if I get stuck

[hpux735 (William Dillon)]

So I see your patch, and that makes sense. Where I'm a little stuck is that the portfiles for the cross tools are all made with that tcl script, and I'm not really familiar with how to "hook" into it. Do you have any advice?

[GarrettAlbright (Garrett Albright)]

Bumping this because I'd like to use it, but I'm just not smart enough about how compilers work to know where to begin on patching it as was discussed above. I'll put a bounty of US$20 out there for anyone that can get this installable on the M1 before the end of May 2021.

[irdc]

Fix for build on M1

[irdc]

People doing RISC-V cross-compiles have already ran into this as well, and have found a fix: ​https://github.com/riscv-software-src/homebrew-riscv/issues/47#issuecomment-772306695. Note that this is said to disable pre-compiled headers and thus incurs a performance hit for those projects using these. I've attached a patch and can confirm I can build this port with the patch applied.

[johankytt]

Tried applying the patch by irdc. Makes no difference, still exactly the same error as in the original post. I assume "/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/cross/arm-none-eabi-gcc/work/gcc-11.3.0/gcc/config.host" is the correct file to patch? grep found no other file containing the lines from the patch.

[cooljeanius (Eric Gallager)]

Replying to hpux735:

It looks like this might be the upstream bug?

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

That's closed now though...

[ryandesign (Ryan Carsten Schmidt)]

We have successful builds of arm-none-eabi-gcc on macOS 11 and 12 on arm64 now, and the build failure on macOS 13 (which is not arm64-specific) is being tracked in #67737. So this must've gotten fixed somewhere along the way, maybe by updating to a new version. (We're currently on 13.1.0).