Add GCC
The official name of the app GCC
Proposed App Status Native - not yet. Rosetta - no idea.
Related Issue Tracker Link or discussion https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96168
An Official App Download Link https://gcc.gnu.org/
Additional context
Thanks for the App Request!
Next, we'll need to have it next on Rosetta to or find a confirmation that someone already has
Works using Rosetta (and what's interesting, file $(which gcc) says gcc is universal binary so should work natively, but I'll test that some time later).
Edit: and I'm a little weirded out by clang appearing as on Linux it says gcc, but I guess that's normal on macs?
We'll go with "✳️ Yes, runs via Rosetta 2" for now but leave this issue open until native ARM Support is released publicly
This is ready to add to the list.
- GNU Compiler Collection - ✳️ Yes, runs via Rosetta 2 - Source Bugzilla Issue
Feel free to make a pull request using the App Addition Template otherwise I'll add it when time permits.
Just to add to this discussion, the GCC ARM Embedded (used for micro controllers and embedded devices) also works fine using rosetta.
@pawelostr
Edit: and I'm a little weirded out by clang appearing as on Linux it says gcc, but I guess that's normal on macs?
The gcc that ships with the command line tools is just a wrapper to clang. You should change your PATH variable to point to the new gcc installed by homebrew.
Here's what I got by running gcc --version:
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 12.0.0 (clang-1200.0.32.28)
Target: arm64-apple-darwin20.2.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
Macports has a native version of gcc for the devel branch (gcc 11)
$ file /opt/local/bin/gcc-mp-devel
/opt/local/bin/gcc-mp-devel: Mach-O 64-bit executable arm64
$ gcc-mp-devel --version
gcc-mp-devel (MacPorts gcc-devel 11-20201205_0) 11.0.0 20201205 (experimental)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
@fabiojmendes Drop a screenshot for GCC ARM Embedded and we'll go ahead and add it to the list.
Be sure to include the App, Activity Monitor showing the app details, and About this Mac so we can see the exact OS version.
You can find an example on #358
Native support is still a work in progress. This repo tracks that: https://github.com/iains/gcc-darwin-arm64.
For the arm-none-eabi version of GCC for building embedded stuff, I've got a working m1 build. https://github.com/SeanMollet/arm-none-eabi-gcc-aarch64-macosx
@ThatGuySam I've got an M1 build for this specific gcc: https://doesitarm.com/app/gcc-arm-embedded/ Screenshot attached.

Updated!
https://doesitarm.com/app/gcc-arm-embedded/
Thanks for the screenshots @SeanMollet!
Are GCC and GCC-ARM-embedded different products?
@moffpage Do you know if GCC-ARM-embedded is Apple Silicon native yet?
Um, the comment before mine literally updates the info on that regard: https://doesitarm.com/app/gcc-arm-embedded/
@moffpage GCC is the "GNU Compiler Collection", it comprises many, many compilers. There isn't currently one that can build things for MacOS arm. I built one that can build things for embedded arm devices that runs on MacOS arm. So, yes, GCC and GCC-ARM-Embedded are different "products".
Thanks for clarifying!
@SeanMollet, @ThatGuySam,
- What is the current status of gcc-arm for M1? I see doesitarm.com claiming "full native M1 support" but the binaries from developers.arm.com (and by extension the homebrew provided version) still ship x86_64 ones.
- Is the cask in https://github.com/SeanMollet/arm-none-eabi-gcc-aarch64-macosx being maintained?
- Last - what does doesitarm.com track generally? Is it the availability of a package in native M1 arch (via established package manager, or download sites) or just the a possibility of being able to build one yourself is enough to call a "full support"?
@sidcha
- Arm isn't building it for some reason. I am.
- Yes. I noticed recently that there's a new release, I'll probably build it and put out an update in a week or two
- I'm not the person to answer that.
Here's my take: I made the necessary changes to get it to build on M1, documented them and built a binary with it. I make both the resulting binary and the requisite bits and documentation required for you to build it yourself available if you don't trust my binary.
If we were talking about a consumer app, I would say the line belongs at "signed binary distributed by the author." But, we're talking about an embedded C compiler here. This is something used by people that know how to build software. So, having a repo available that builds and works correctly on M1 is probably sufficient. A pre-built binary bundle is a bonus.
@SeanMollet, Thanks for your efforts and the answers. I resorted to building from source (with your instructions); not that I don't trust you, your binaries weren't signed. Perhaps you could sign future releases?
I will wait for @ThatGuySam to answer 3/ then :)
Last - what does doesitarm.com track generally? Is it the availability of a package in native M1 arch (via established package manager, or download sites) or just the a possibility of being able to build one yourself is enough to call a "full support"?
@sidcha I try to track against what most of the community and users of the specific software would consider "ARM Native" and not assume what I consider "ARM Native" is the same as the people who actually use the software.
If people that use the software mostly build from source every time and that's working then yes.
If people that use the software only get it through DMG or even the Mac App Store then I'll try to go off that.
One example is OBS, there are "ARM Native" builds but Youtube and Twitch streamers wouldn't consider that fully native.
Generally, if the software publisher distributes an ARM-compatible version it's likely considered "ARM Native"