Unable to build vim formula on ARM64 Ubuntu Host

[PatTheMav]

Additional Info

• I am using Windows Subsystem for Linux

Output of brew config

HOMEBREW_VERSION: 4.6.7
ORIGIN: https://github.com/Homebrew/brew
HEAD: 02947ea4edbdef5fcce9ee57fa289547f4d096c9
Last commit: 26 hours ago
Branch: stable
Core tap JSON: 25 Aug 20:02 UTC
HOMEBREW_PREFIX: /home/linuxbrew/.linuxbrew
HOMEBREW_BAT_THEME: mariana
HOMEBREW_CASK_OPTS: []
HOMEBREW_DISPLAY: :0
HOMEBREW_EDITOR: /usr/bin/vim
HOMEBREW_FORBID_PACKAGES_FROM_PATHS: set
HOMEBREW_INSTALL_BADGE: 💾 
HOMEBREW_MAKE_JOBS: 2
HOMEBREW_NO_ENV_HINTS: set
HOMEBREW_VERBOSE_USING_DOTS: set
Homebrew Ruby: 3.4.5 => /home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/vendor/portable-ruby/3.4.5/bin/ruby
CPU: dual-core 64-bit arm
Clang: N/A
Git: 2.51.0 => /home/linuxbrew/.linuxbrew/bin/git
Curl: 8.12.1 => /bin/curl
Kernel: Linux 6.14.0-28-generic aarch64 GNU/Linux
OS: Ubuntu 25.04 (plucky)
Host glibc: 2.41
/usr/bin/gcc: 14.2.0
/usr/bin/ruby: N/A
glibc: N/A
gcc@11: N/A
gcc: N/A
xorg: N/A

Output of brew doctor

Please note that these warnings are just used to help the Homebrew maintainers
with debugging if you file an issue. If everything you use Homebrew for is
working fine: please don't worry or file an issue; just ignore this. Thanks!

Warning: Your CPU architecture (arm64) is not supported. We only support
x86_64 CPU architectures. You will be unable to use binary packages (bottles).

This is a Tier 2 configuration:
  https://docs.brew.sh/Support-Tiers#tier-2
You can report Tier 2 unrelated issues to Homebrew/* repositories!
Read the above document instead before opening any issues or PRs.

Description of issue

I am aware of Homebrew/brew#19208 and Homebrew/homebrew-core#211761 and as the brew doctor output makes it clear above, ARM64 on Linux is a Tier 2 configuration, hence why I'm opening a discussion thread instead.

So far I've been able to install bottled formulas without issue, but trying to build vim (either the official formula or my variant from a custom tap) fails during its configure step:

Custom tap with slimmed-down vim:

==> Installing vim-custom from patthemav/custom
==> ./configure --prefix=/home/linuxbrew/.linuxbrew --mandir=/home/linuxbrew/.linuxbrew/Cellar/vim-custom/9.1.1550/share/man --enable-multibyte --with-tl
Last 15 lines from /home/ptm/.cache/Homebrew/Logs/vim-custom/01.configure.log:
--enable-gui=no
--without-x
--disable-selinux
--disable-nls

configure: creating cache auto/config.cache
checking whether make sets $(MAKE)... yes
checking for gcc... gcc-14
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... configure: error: in '/var/tmp/vim-custom-20250825-85087-djgwdf/vim-9.1.1550/src':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use '--host'.
See 'config.log' for more details

Official vim formula

==> Installing vim --HEAD
==> ./configure --prefix=/home/linuxbrew/.linuxbrew --mandir=/home/linuxbrew/.linuxbrew/Cellar/vim/HEAD-3b3b936/share/man --enable-multibyte --with-tlib=
Last 15 lines from /home/ptm/.cache/Homebrew/Logs/vim/01.configure.log:
--disable-gui
--without-x
--enable-luainterp
--with-lua-prefix=/home/linuxbrew/.linuxbrew/opt/lua

configure: creating cache auto/config.cache
checking whether make sets $(MAKE)... yes
checking for gcc... gcc-14
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... configure: error: in '/var/tmp/vim-20250825-83803-pqpvgv/src':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use '--host'.
See 'config.log' for more details

The conftest binary generated by the configure script for the "cross compilation check" outright crashes. But this does not happen when I check out vim separately and run the same configure command: The script runs to completion with a configured build system.

Per Homebrew-on-Linux I ran sudo apt-get install build-essential procps curl file git to ensure the build dependencies are present on the system.

Does anyone have an idea what the root cause here is, maybe I'm missing some configuration or necessary dependency on my system? Because it should work (otherwise there would not be ARM64 bottles available).

[Bo98]

Check ~/.cache/Homebrew/Logs/vim for further logs. In particular, config.log would be useful.

[PatTheMav]

Here's what lscpu reports inside the VM:

Architecture:                aarch64
  CPU op-mode(s):            64-bit
  Byte Order:                Little Endian
CPU(s):                      2
  On-line CPU(s) list:       0,1
Vendor ID:                   ARM
  Model name:                -
    Model:                   0
    Thread(s) per core:      1
    Core(s) per cluster:     2
    Socket(s):               -
    Cluster(s):              1
    Stepping:                r0p0
    BogoMIPS:                48.00
    Flags:                   fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 asimddp sha512 as
                             imdfhm dit uscat ilrcpc flagm sb paca pacg dcpodp flagm2 frint
NUMA:                        
  NUMA node(s):              1
  NUMA node0 CPU(s):         0,1
Vulnerabilities:             
  Gather data sampling:      Not affected
  Ghostwrite:                Not affected
  Indirect target selection: Not affected
  Itlb multihit:             Not affected
  L1tf:                      Not affected
  Mds:                       Not affected
  Meltdown:                  Not affected
  Mmio stale data:           Not affected
  Reg file data sampling:    Not affected
  Retbleed:                  Not affected
  Spec rstack overflow:      Not affected
  Spec store bypass:         Vulnerable
  Spectre v1:                Mitigation; __user pointer sanitization
  Spectre v2:                Mitigation; CSV2, but not BHB
  Srbds:                     Not affected
  Tsx async abort:           Not affected

[PatTheMav]

On a whim I tried all this with clang provided by Ubuntu 25 and the binary just works. I don't understand enough about the PAC/BTI features to be able to tell which instructions clang uses to make it work, though it looks as if it detects the availability of the features as well:

        .aeabi_subsection       aeabi_feature_and_bits, optional, uleb128
        .aeabi_attribute        Tag_Feature_BTI, 1
        .aeabi_attribute        Tag_Feature_PAC, 1
        .aeabi_attribute        Tag_Feature_GCS, 1

Both gcc and clang use the hint instruction, which supposedly should either use the feature or result in a NOOP otherwise, but - alas - that's kinda where my understanding ends.

Right now the bottles produced for ARM64 do not have BTI or PAC enabled (one can check via readelf -n), probably because arch=armv8-a is enforced for the container.

If I tweak my formula to require llvm for Linux and ARM, I get a working binary that does indeed advertise to have both enabled.

[PatTheMav]

Final insight for tonight - I've found this blog post by ARM which made me check if gcc-15 (available via Homebrew) fares better.

And indeed after I added a fails_with block to my formula for gcc-14 to ensure that Homebrew's gcc is used everything worked.

Here are the differences in assembly (gcc-14 variant on the left, gcc-15 variant on the right):

──────────────────────┐
• conftest_gcc15.s:1: │
──────────────────────┘
│  1 │        .arch armv8-a+flagm+lse+dotprod+rdma+crc+aes+sha↵ │  1 │        .arch armv8-a+flagm2+lse+dotprod+rdma+crc+aes+sh↵
│    │3+fp16fml+rcpc+sb+pauth                                   │    │a3+fp16fml+jscvt+fcma+rcpc2+frintts+sb+pauth
│  2 │        .file        "conftest.c"                         │  2 │        .file        "conftest.c"
│  3 │        .text                                             │  3 │        .text
│  4 │        .section        .rodata                           │  4 │        .section        .rodata

─────────────────────────────┐
• conftest_gcc15.s:16: main: │
─────────────────────────────┘
│ 16 │.LFB0:                                                    │ 16 │.LFB0:
│ 17 │        .cfi_startproc                                    │ 17 │        .cfi_startproc
│ 18 │        hint        25 // paciasp                         │ 18 │        hint        25 // paciasp
│ 19 │        .cfi_window_save                                  │    │
│    │                                                          │ 19 │        .cfi_negate_ra_state
│ 20 │        stp        x29, x30, [sp, -32]!                   │ 20 │        stp        x29, x30, [sp, -32]!
│ 21 │        .cfi_def_cfa_offset 32                            │ 21 │        .cfi_def_cfa_offset 32
│ 22 │        .cfi_offset 29, -32                               │ 22 │        .cfi_offset 29, -32

─────────────────────────────┐
• conftest_gcc15.s:52: main: │
─────────────────────────────┘
│ 52 │        .cfi_restore 30                                   │ 52 │        .cfi_restore 30
│ 53 │        .cfi_restore 29                                   │ 53 │        .cfi_restore 29
│ 54 │        .cfi_def_cfa_offset 0                             │ 54 │        .cfi_def_cfa_offset 0
│ 55 │        hint        29 // autiasp                         │    │
│ 56 │        .cfi_window_save                                  │    │
│ 57 │        retaa                                             │ 55 │        retaa
│ 58 │        .cfi_endproc                                      │ 56 │        .cfi_endproc
│ 59 │.LFE0:                                                    │ 57 │.LFE0:
│ 60 │        .size        main, .-main                         │ 58 │        .size        main, .-main
│ 61 │        .ident        "GCC: (Ubuntu 14.2.0-19ubuntu2) 14↴ │ 59 │        .ident        "GCC: (Homebrew GCC 15.1.0) 15.1.0"
│    │                                                   ….2.0" │    │
│ 62 │        .section        .note.GNU-stack,"",@progbits      │ 60 │        .section        .note.GNU-stack,"",@progbits
│ 63 │        .section        .note.gnu.property,"a"            │ 61 │        .section        .note.gnu.property,"a"
│ 64 │        .align        3                                   │ 62 │        .align        3

─────────────────────────────┐
• conftest_gcc15.s:66: main: │
─────────────────────────────┘
│ 68 │        .string        "GNU"                              │ 66 │        .string        "GNU"
│ 69 │        .word        3221225472                           │ 67 │        .word        3221225472
│ 70 │        .word        4                                    │ 68 │        .word        4
│ 71 │        .word        3                                    │ 69 │        .word        7
│ 72 │        .align        3                                   │ 70 │        .align        3

Noteably readelf -n shows neither BTI nor PAC support for the binary generated by gcc-15 (it still does when compiled with clang however).

[Bo98]

Looks like you're hitting https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119372. This is fixed in GCC 14.3 (released in May) but you're still running GCC 14.2. You'll need to ask Ubuntu when they'll be updating to 14.3 or you could report this (the insertion of autiasp before retaa) to Ubuntu as a standalone bug and they may backport the bug fix to their GCC 14.2 builds in the meantime.

I might see if we can detect this on the Homebrew side and work around it, though we don't really do much minor-version tracking at the moment.

Since you're using Ubuntu 25.04, they do also have GCC 15 which could install and use update-alternatives to point to. Or just use the Homebrew one (or even Homebrew's gcc@14), whatever you prefer.

Ubuntu 25.10 afaik will update the default to GCC 15.

[PatTheMav]

D'oh, could've looked up the GCC bug tracker myself. It's spot on.

From what I could tell this seems to affect gcc-11 through gcc-14 and is fixed by a minor release that is not yet available on Ubuntu 25. And it also means that custom taps without bottles and installing any formula with --HEAD on an ARM64 box can potentially fail to compile based on whichever minor version of the compiler is installed on the host machine.

A fails_with :gcc do <..> end is not able to check for a specific minor version as you mentioned and updating every formula to use a on_linux do on_arm do <..> end end block to require gcc from Homebrew is also not feasible imo.

It's fine insofar as ARM64 support on Linux is Tier 2 and not officially available and maybe this problem solves itself by having these fixed variants available by default by then. But it also shows a possible breaking point in the future that Homebrew has no good way to catch/work around.

As a user the only options I have are:

• Install gcc via Homebrew (it sounds like it will be preferred over the one provided via system packages) hoping it contains the fix to whichever bug the system package variant has
• Change the formula to require Homebrew's gcc for building or
• Change the formula to force the use of -march=armv8.3-a+pauth instead of -march=native (brittle as it hard-codes a specific architecture)

And I haven't found a way to be able to influence the superenv in generic fashion to do this instead (I can see good reasons for why that shouldn't be possible as it introduces maintenance burden similar to the build options Formulas provided back in the day).

---

That said I'm fine with this for now, we identified the issue and the root cause, locally I was able to build with gcc-15 installed via Homebrew, but maybe something to be on the look out for particularly for custom taps or otherwise unbottled Formulas/Formulas built from HEAD.

[carlocab]

You can set HOMEBREW_ARCH for your own builds on Linux. From man brew:

HOMEBREW_ARCH
       Linux only: Pass this value to a type name representing the compiler’s -march option.
                                                                                             
       Default: native.

[PatTheMav]

You can set HOMEBREW_ARCH for your own builds on Linux. From man brew:

HOMEBREW_ARCH
       Linux only: Pass this value to a type name representing the compiler’s -march option.
                                                                                             
       Default: native.

Nice that would indeed solve as an "outside" fix for this specific issue. Would require knowing/understanding that this is specifically the issue, but - again - Tier 2 and all. 😅