Linux gcc formula (gcc-15) doesn't use the brew binutils as, so breaks on ".base64" assembly instruction

[c-kloukinas]

Additional Info

• I am using Windows Subsystem for Linux

Output of brew config

HOMEBREW_VERSION: 4.5.7
ORIGIN: https://github.com/Homebrew/brew
HEAD: 6301c2d31f8dc07d2d16ddaa33711cf5a41d4e17
Last commit: 5 days ago
Branch: stable
Core tap JSON: 19 Jun 14:53 UTC
HOMEBREW_PREFIX: /home/linuxbrew/.linuxbrew
HOMEBREW_CASK_OPTS: []
HOMEBREW_DISPLAY: :0.0
HOMEBREW_MAKE_JOBS: 20
Homebrew Ruby: 3.4.4 => /home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/vendor/portable-ruby/3.4.4/bin/ruby
CPU: 20-core 64-bit alderlake
Clang: 18.1.3
Git: 2.43.0 => /bin/git
Curl: 8.5.0 => /bin/curl
Kernel: Linux 6.6.87.2-microsoft-standard-WSL2 x86_64 GNU/Linux
OS: Ubuntu 24.04.2 LTS (noble)
WSL: 2 (Microsoft Store)
Host glibc: 2.39
/usr/bin/gcc: 13.3.0
/usr/bin/ruby: 3.2.3
glibc: N/A
gcc@11: N/A
gcc: 15.1.0
xorg: N/A

Output of brew doctor

Your system is ready to brew.

Description of issue

gcc declares binutils as a dependency on Linux but the compiler (gcc-15) doesn't call the brew binutils "as" explicitly, so gets an older Linux version that doesn't know what .base64 is:

$ PATH=/home/linuxbrew/.linuxbrew/Cellar/binutils/2.44/bin:$PATH make  as-check.o
gcc-15    -c -o as-check.o as-check.c
$ rm as-check.o ; make as-check.o
gcc-15    -c -o as-check.o as-check.c
/tmp/cceFSnag.s: Assembler messages:
/tmp/cceFSnag.s:25: Error: unknown pseudo-op: `.base64'
make: *** [<builtin>: as-check.o] Error 1
$ type -a as gcc-15
as is /usr/bin/as
as is /bin/as
gcc-15 is /home/linuxbrew/.linuxbrew/bin/gcc-15
gcc-15 is /home/linuxbrew/.linuxbrew/bin/gcc-15
$ /usr/bin/as --version
GNU assembler (GNU Binutils for Ubuntu) 2.42
Copyright (C) 2024 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `x86_64-linux-gnu'.
$ /home/linuxbrew/.linuxbrew/Cellar/binutils/2.44/bin/as --version
GNU assembler (GNU Binutils) 2.44
Copyright (C) 2025 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `x86_64-pc-linux-gnu'.
$ cat as-check.c
void s61() { static char extra_special_characters[] = "\n\t\b\r\f\\\'"; }
$

I got the test code (as-check.c) from the following bug report (not smart enough to write my own...)
https://gcc.gnu.org/pipermail/gcc-bugs/2024-October/886677.html

I tried uninstalling and re-installing gcc & binutils - same behaviour.

[arnavk23]

[SMillerDev]

Or provide guidance in post-install messages for overriding default system tools

This shouldn't be needed because Homebrew already puts itself as the first path entry. Did you actually check the issue situation or did you just use an LLM to come up with the answer?

[c-kloukinas]

Hi @SMillerDev , as & the other binutils are not linked in the main brew directory that is included in the path, they're in their own optional directory. So Homebrew's path's position doesn't matter.
It shouldn't matter even if Homebrew was in the last position in my view:
If I call gcc-15, and that's the only gcc-15 anywhere in my path, then that gcc-15 should use the correct version of binutils when it runs, instead of crapping out by calling whatever happens to be first in the path. And that's because I tried to execute a compiler, not the assembler directly, so since the compiler works as a wrapper, it should wrap the correct thing.

[Why it matters to me - I'm teaching C++ and using brew to ensure that all students have the exact same compiler, whether they use a Mac, Windows/WSL, or Linux OS. So if the compiler dies unexpectedly, because it's calling the wrong assembler internally, then they're in trouble - they cannot figure out what's going on.]

BTW, I'm curious - did you actually check the issue situation?

[term-est]

@c-kloukinas This is not a brew problem, you have a toolchain mismatch that needs to be taken care of in your environment. GCC15 uses binutils 2.43+, whose gas has the .base64 directive which is emitted by GCC

What you can do is install a recent binutils and add that to your path. Here are the instructions for it

brew install binutils

sudo update-alternatives \
  --install /usr/bin/as as /home/linuxbrew/.linuxbrew/opt/binutils/bin/as 100 \
  --slave /usr/bin/ld ld /home/linuxbrew/.linuxbrew/opt/binutils/bin/ld \
  --slave /usr/bin/nm nm /home/linuxbrew/.linuxbrew/opt/binutils/bin/nm \
  --slave /usr/bin/objdump objdump /home/linuxbrew/.linuxbrew/opt/binutils/bin/objdump \
  --slave /usr/bin/objcopy objcopy /home/linuxbrew/.linuxbrew/opt/binutils/bin/objcopy \
  --slave /usr/bin/strip strip /home/linuxbrew/.linuxbrew/opt/binutils/bin/strip
  
  sudo update-alternatives --config as

and then you can invoke GCC15

[c-kloukinas]

Hi @term-est , when I look at the gcc formula, binutils are not stated as a dependency.
So, if they are needed (I believe that in this situation they're needed indeed), then they should be stated as a dependency. In the previous versions, they were actually not needed - the normal as/ld would work fine. But here they are needed.

So, once binutils are stated as a dependency, as they should be, then the question becomes - what should this formula do with them?
Perform the action you suggest and add them in the path?
Keep them in the opt directory but configure gcc-15 to use them from there?
Something else entirely?

In either case, someone who installs gcc (gcc-15) shouldn't have to bother with binutils - they've asked for gcc, brew said it installed it, so gcc should just work. But it doesn't.

I see that this issue has affected another formula

[byxrolland]

I tried to solve some similar issues with

brew link binutils --force

and it worked.

Perhaps this can also help you? I am not an expert for Linux. I'm not sure if they can cause other troubles.

[c-kloukinas]

Thanks @byxrolland , appreciate you taking time to help!
I've actually downgraded to gcc-14, because I consider this formula/gcc version to be broken (doesn't list all its dependencies).
I understand that placing binutils on the path before the default ones may cause issues (which is probaly why they're not placed there by default and the user has to do it explicitly).

One solution may be to create wrappers for gcc-15 that use the correct paths.
But even that is tricky - if one compiles a set of object files and then tries to link them with ld then they'll probably fail.

Maybe gcc needs to add a command line arg to select the new as/ld (so that whomever knows/cares about them and wants to use them can do so) but by default use the old ones, so that everyone can keep their sanity.