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

@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

@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

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

@ThatGuySam I've got an M1 build for this specific gcc: https://doesitarm.com/app/gcc-arm-embedded/ Screenshot attached.

@SeanMollet

Updated!

https://doesitarm.com/app/gcc-arm-embedded/

Thanks for the screenshots @SeanMollet!

Are GCC and GCC-ARM-embedded different products?

@moffpage

@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

@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

@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

@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

@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 :)

@sidcha

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"

Refresh oldest app requests and recognize current macOS ARM bottles

@pawelostr

Thanks @pawelostr for the request, and @fabiojmendes, @SeanMollet and @sidcha for helping clarify the compiler and distribution differences! I've updated GNU Compiler Collection to native support via Homebrew's ARM packages, replacing the old Apple Clang screenshot as evidence for GNU GCC. The embedded cross-compiler remains a separate listing.

Listings: GNU Compiler Collection and GCC ARM Embedded.

Changes pushed in 1723f49. The API and frontend deployments passed, and the listing names, status wording, versions where specified, and evidence-link labels above were checked on the public pages. The new Homebrew regression tests and README validation passed in CI. Live page verification is not a claim that I ran these Mac apps locally. Closing this listing request after maintainer review.

Feel free to browse the app list and suggest another app you'd like us to review!

Navigation Menu

Repository navigation

Add GCC #105

2 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Add GCC #105

Description

Activity

ThatGuySam commented on Nov 14, 2020

pawelostr commented on Nov 24, 2020

ThatGuySam commented on Nov 24, 2020

ThatGuySam commented on Nov 24, 2020

fabiojmendes commented on Dec 23, 2020

fabiojmendes commented on Dec 23, 2020

ThatGuySam commented on Dec 23, 2020

fabiojmendes commented on Dec 23, 2020

2 remaining items

SeanMollet commented on Apr 26, 2021

SeanMollet commented on May 16, 2021

ThatGuySam commented on May 17, 2021

moffpage commented on May 21, 2021

ThatGuySam commented on May 21, 2021

moffpage commented on May 21, 2021

SeanMollet commented on May 21, 2021

moffpage commented on May 22, 2021

sidcha commented on Feb 20, 2022

SeanMollet commented on Feb 20, 2022

sidcha commented on Feb 20, 2022

ThatGuySam commented on Feb 26, 2022

ThatGuySam commented on Sep 7, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions