libgcc14 (libgcc14-14.2.0_1+stdlib_flag.darwin_24.arm64.tbz2) failed to build with config error ("configure: error: cannot compute suffix of object files: cannot compile") on macOS Sequoia beta 15.0 Beta (24A5327a)

[avisformosa]

Dear MacPorts community! As described above I negligently updated to the beta of Sequoia (15.0 Beta (24A5327a)). As far as I can tell, the Xcode beta and the Command Line Tools are up to date with the beta, and most things compile without problems, but unfortunately, libgcc fails with the following error:

:info:build checking for aarch64-apple-darwin24-gcc... /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc14/libgcc14/work/build/./gcc/xgcc -B/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc14/libgcc14/work/build/./gcc/ -B/opt/local/aarch64-apple-darwin24/bin/ -B/opt/local/aarch64-apple-darwin24/lib/ -isystem /opt/local/aarch64-apple-darwin24/include -isystem /opt/local/aarch64-apple-darwin24/sys-include   -fno-checking
:info:build checking for suffix of object files... configure: error: in `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc14/libgcc14/work/build/aarch64-apple-darwin24/libgcc':
:info:build configure: error: cannot compute suffix of object files: cannot compile
:info:build See `config.log' for more details
:info:build make[2]: *** [configure-stage1-target-libgcc] Error 1
:info:build make[2]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc14/libgcc14/work/build'
:info:build make[1]: *** [stage1-bubble] Error 2
:info:build make[1]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc14/libgcc14/work/build'
:info:build make: *** [bootstrap-lean] Error 2
:info:build make: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc14/libgcc14/work/build'
:info:build Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc14/libgcc14/work/build" && /usr/bin/make -j8 -w bootstrap-lean 
:info:build Exit code: 2
:error:build Failed to build libgcc14: command execution failed
:debug:build Error code: CHILDSTATUS 87166 2
:debug:build Backtrace: command execution failed
:debug:build     while executing
:debug:build "system {*}$notty {*}$callback {*}$nice $fullcmdstring"
:debug:build     invoked from within
:debug:build "command_exec -callback portprogress::target_progress_callback build"
:debug:build     (procedure "portbuild::build_main" line 10)
:debug:build     invoked from within
:debug:build "$procedure $targetname"
:error:build See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc14/libgcc14/main.log for details.

Any suggestions or is this a generic bug as the "configure: error: cannot compute suffix of object files: cannot compile"-Error is somewhat general - but I did not find any useful work around. Thanks!

[oversized-monday (MONDAY!)]

I poked at this a little bit and when trying to recreate the configure failure, I get an error about -lemutls_w not being found. I'm not familiar with gcc, but this seems to be a library for emulating thread local storage on systems that don't have it. The macports Portfile specifies --disable-tls which suggests that it should be disabled. I don't know if this is a problem with my tests or a hint at the actual problem.

Hopefully this helps point someone more knowledgeable in the right direction.

[ryandesign (Ryan Carsten Schmidt)]

Please attach the main.log and config.log files.

[avisformosa]

Main log libgcc14 - due to size in two parts

[avisformosa]

Main log libgcc14 - due to size in two parts

[avisformosa]

config log from port work libgcc14

[kencu (Ken)]

I don't think the config.log you posted is the one with the error in it.

Noted there is a bug with the latest Xcode that prevents building gcc:

​https://github.com/iains/gcc-darwin-arm64/issues/136

[oversized-monday (MONDAY!)]

I manually removed "-pipe" from the gcc14 and libgcc14 Makefiles (after a failed build attempt) and they both built fine. I was able to then build Emacs with native compilation (which uses libgccjit)

I didn't see where gcc14 decides whether to use -pipe when building the Makefiles. If that can be temporarily triggered, we can fix builds while we wait for either Apple to fix their side or for it to be patched upstream by gcc.

[ryandesign (Ryan Carsten Schmidt)]

MacPorts base adds -pipe for all ports if configurepipe is yes in macports.conf, which it is by default.

[oversized-monday (MONDAY!)]

Confirming that setting configurepipe to "no" does work. I did a fresh install and gcc14/libgcc14 built with no issues.

[markemer (Mark Anderson)]

I'll give this a shot later - but I've had issues building gcc/libgcc since the bump to macOS 15.

[amake (Aaron Madlon-Kay)]

I find that setting configurepipe no leads to a different error for me on the final release of Sequoia:

Undefined symbols for architecture x86_64:
  "___deregister_frame_info", referenced from:
     -reexported_symbols_list command line option
  "___deregister_frame_info_bases", referenced from:
     -reexported_symbols_list command line option
  "___register_frame_info", referenced from:
     -reexported_symbols_list command line option
  "___register_frame_info_bases", referenced from:
     -reexported_symbols_list command line option
  "___register_frame_info_table", referenced from:
     -reexported_symbols_list command line option
  "___register_frame_info_table_bases", referenced from:
     -reexported_symbols_list command line option
  "___register_frame_table", referenced from:
     -reexported_symbols_list command line option
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
make[3]: *** [libgcc_s.1.dylib] Error 1

[snowflake (Dave Evans)]

I too get the same errors after fixing the pipe.

System is macOS 15.0 Sequoia newly installed today on an Intel Mac.

[amake (Aaron Madlon-Kay)]

Emacs users can successfully build by disabling the nativecomp variant.

[amake (Aaron Madlon-Kay)]

(accidental double-post)

[cjones051073 (Chris Jones)]

GCC invariably has issues on major OS updates and/or new Xcode versions...

We run in MacPorts Darwin versions from here

​https://github.com/iains/gcc-14-branch

specifically we are running the latest tag, ​https://github.com/iains/gcc-14-branch/releases/tag/gcc-14.2-darwin-r1

The owner of that repo is effectively the Darwin lead in GCC, and very responsive, so please can I request someone running macOS15 (not the beta, the newly available release) and has issues with gcc14 please open an issue against the above repo

​https://github.com/iains/gcc-14-branch/issues

including whatever info you can. At minimum a clean build log for instance.

[markmentovai (Mark Mentovai)]

​https://github.com/macports/macports-ports/compare/master...markmentovai:macports-ports:gcc14_xcode16 addresses this locally for me. I’ll investigate a bit more to see whether this is appropriate for upstream (it probably is) or if it should be a MacPorts-local patch.

[cjones051073 (Chris Jones)]

Thanks. Please do as I suggest, open an issue with upstream at the link I posted, include a complete build log and your proposed fixed and see what he says.

[markmentovai (Mark Mentovai)]

There is already some discussion of this problem at ​https://github.com/iains/gcc-darwin-arm64/issues/136.

[OttoG]

Replying to amake:

Emacs users can successfully build by disabling the nativecomp variant.

Thanks a lot for the tip, that works fine for me, too. I hoped that the same approach might work for octave, but when trying around with different variants, I could not find one that did not depend on libgcc14. On the other hand, I only rarely use Octave, so I will just wait for the AS_NEEDS_DASH_FOR_PIPED_INPUT fix discussed in the gcc-darwin-arm64 repo.

[BarneyStratford]

I've experienced the same problem on port gcc14 as on libgcc14. You can work around it for now on all ports affected by this bug by appending the following to /opt/local/etc/macports/macports.conf:

configurepipe no

[cjones051073 (Chris Jones)]

As a temporary measure until upstream provides a proper fix I have pushed Mark's fix above. see

[048f899dce5faab37c01ced3294fbdf74ede4f03/macports-ports]

As (lib)gcc14 is a dep for a number of ports having it broken will be an issue for many users so having this workaround, for now, is reasonable I would say.

[dbl001 (dbl)]

I just tried and got the same error Aaron reported above:

:info:build Undefined symbols for architecture x86_64:
:info:build   "___deregister_frame_info", referenced from:
:info:build      -reexported_symbols_list command line option
:info:build   "___deregister_frame_info_bases", referenced from:
:info:build      -reexported_symbols_list command line option
:info:build   "___register_frame_info", referenced from:
:info:build      -reexported_symbols_list command line option
:info:build   "___register_frame_info_bases", referenced from:
:info:build      -reexported_symbols_list command line option
:info:build   "___register_frame_info_table", referenced from:
:info:build      -reexported_symbols_list command line option
:info:build   "___register_frame_info_table_bases", referenced from:
:info:build      -reexported_symbols_list command line option
:info:build   "___register_frame_table", referenced from:
:info:build      -reexported_symbols_list command line option
:info:build ld: symbol(s) not found for architecture x86_64

[wdormann]

Just for anyone playing along here... If you are doing the configurepipe no workaround, you will also want to do a sudo port clean --all gcc14 before re-attempting to port install gcc14.

[scentorrino (Samuele Centorrino)]

Same error reported by Aaron and dbl on a clean MacOS 15 install, even after cleaning ports gcc14 and libgcc14.

:info:build Undefined symbols for architecture x86_64:
:info:build   "___deregister_frame_info", referenced from:
:info:build      -reexported_symbols_list command line option
:info:build   "___deregister_frame_info_bases", referenced from:
:info:build      -reexported_symbols_list command line option
:info:build   "___register_frame_info", referenced from:
:info:build      -reexported_symbols_list command line option
:info:build   "___register_frame_info_bases", referenced from:
:info:build      -reexported_symbols_list command line option
:info:build   "___register_frame_info_table", referenced from:
:info:build      -reexported_symbols_list command line option
:info:build   "___register_frame_info_table_bases", referenced from:
:info:build      -reexported_symbols_list command line option
:info:build   "___register_frame_table", referenced from:
:info:build      -reexported_symbols_list command line option
:info:build ld: symbol(s) not found for architecture x86_64
:info:build collect2: error: ld returned 1 exit status

[Bradford-Miller (Bradford Miller)]

Replying to dbl001:

I just tried and got the same error Aaron reported above:

I nuked my /opt/local directory and retried from scratch (not changing my MacPorts.conf file or anything). I successfully installed on an M1 Mac, but my x86 Macs get this error as well.

[markemer (Mark Anderson)]

Also, you cannot remove configurepipe no or some things will fail when you try to use the compilers. I ran into this with gfortran

[dbl001 (dbl)]

Why are ___register_frame_table and ___register_frame_info_bases missing with -reexported_symbols_list on x86 Macs but not on M Macs? What library is missing or incomplete?

[markmentovai (Mark Mentovai)]

GCC bug filed for the -pipe concern: ​https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116794.

[markmentovai (Mark Mentovai)]

Upstream GCC fix landed (so far only on trunk): ​https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=33ccc1314dcdb0b988a9276ca6b6ce9b07bea21e

[markmentovai (Mark Mentovai)]

Replying to dbl001:

Why are ___register_frame_table and ___register_frame_info_bases missing with -reexported_symbols_list on x86 Macs but not on M Macs? What library is missing or incomplete?

These symbols, __{,de}register_frame_{info,table}*, have indeed been removed from the macOS 15 SDK for both architectures.

The GCC build for mac-x86_64 builds libgcc_s.1, but mac-arm64 does not. Observe ​x86_64 vs. ​arm64.

​GCC 7add7f7bb3d3 has more details on the provision of libgcc_s.1.

[reneeotten (Renee Otten)]

@cjones051073 @markmentovai it's not completely clear to me from the discussion above whether this is supposed to fix the builds. If so, it doesn't for me on

macOS 15.0 24A335 x86_64
Xcode 16.0 16A242d

the currently available Portfile fails with the same undefined symbols error as mentioned earlier in this thread:

:info:build Undefined symbols for architecture x86_64:
:info:build   "___deregister_frame_info", referenced from:
:info:build      -reexported_symbols_list command line option
:info:build   "___deregister_frame_info_bases", referenced from:
:info:build      -reexported_symbols_list command line option
:info:build   "___register_frame_info", referenced from:
:info:build      -reexported_symbols_list command line option
:info:build   "___register_frame_info_bases", referenced from:
:info:build      -reexported_symbols_list command line option
:info:build   "___register_frame_info_table", referenced from:
:info:build      -reexported_symbols_list command line option
:info:build   "___register_frame_info_table_bases", referenced from:
:info:build      -reexported_symbols_list command line option
:info:build   "___register_frame_table", referenced from:
:info:build      -reexported_symbols_list command line option
:info:build ld: symbol(s) not found for architecture x86_64
:info:build collect2: error: ld returned 1 exit status
:info:build make[3]: *** [libgcc_s.1.dylib] Error 1

[markmentovai (Mark Mentovai)]

Replying to reneeotten:

@cjones051073 @markmentovai it's not completely clear to me from the discussion above whether this is supposed to fix the builds. If so, it doesn't for me on

macOS 15.0 24A335 x86_64
Xcode 16.0 16A242d

This bug, as filed, about this error:

configure: error: cannot compute suffix of object files: cannot compile

is fixed for gcc14 as of ​048f899dce5f, and is now fixed on the gcc trunk at ​gcc 33ccc1314dcd. That’s sufficient to make gcc14 build and work properly on mac-arm64 with Xcode 16.

There’s a separate problem, which is not what this bug was originally filed about, concerning a handful of libunwind symbols (__{,de}register_frame_{info,table}*) that are no longer available in macOS 15 or the macOS 15 SDK in Xcode 16. These are only a factor in the gcc build on mac-x86_64.

The situation right now is that gcc14 builds and works on mac-arm64, but is still broken on mac-x86_64. This is true for macOS 15, and also for macOS 14 using Xcode 16.

I have no opinion on whether the libunwind problem should be dealt with under this bug, or a new bug should be filed. But I’m aware of the problem and intend to deal with it either way.

[cjones051073 (Chris Jones)]

As the issue in this ticket is fixed it should be closed. Please open a new one for the x86_64 libunwind issue.

[cjones051073 (Chris Jones)]

Probably the first port of call would be to open a new upstream issue at ​https://github.com/iains/gcc-14-branch/issues

[haberg-1 (Hans Åberg)]

It just failed with 'port install gcc14' on Intel, and the ticket I filed was redirected here. I will retry to see what the issue is.

[cjones051073 (Chris Jones)]

If you are on arm the issue here should be fixed so check your ports are up to date and try again.

If you are on an Intel machine there is a different issue to be addressed.

[haberg-1 (Hans Åberg)]

It still fails to build libgcc14 on Intel, as when redirected to this ticket.

[markmentovai (Mark Mentovai)]

Replying to cjones051073:

Probably the first port of call would be to open a new upstream issue at ​https://github.com/iains/gcc-14-branch/issues

The unwind problem is not specific to mac-arm64 or Iain's branch. It should be filed in upstream gcc's bugzilla. ​That's what Iain suggested.

I've researched the unwind problem and have a fix in mind, and when I have a moment, I will file it. I'll even add a new MacPorts bug to track it here, and link to it from this bug.

[haberg-1 (Hans Åberg)]

FYI, gmp currently fails on 'make check' when compiled with clang, but passes with gcc, so depending ports should use the latter.

[cjones051073 (Chris Jones)]

Not relevant to this ticket. Open a new open against gmp.

[EvilJordan (Jordan Holberg)]

Replying to cjones051073:

If you are on arm the issue here should be fixed so check your ports are up to date and try again.

If you are on an Intel machine there is a different issue to be addressed.

I'm on an arm M1 mac and it's still failing for me after a port clean libgcc14 and then post install libgcc14. Have I missed a step or is the upstream fix not yet available?

info:build checking for aarch64-apple-darwin24-gcc... /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc14/libgcc14/work/build/./gcc/xgcc -B/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc14/libgcc14/work/build/./gcc/ -B/opt/local/aarch64-apple-darwin24/bin/ -B/opt/local/aarch64-apple-darwin24/lib/ -isystem /opt/local/aarch64-apple-darwin24/include -isystem /opt/local/aarch64-apple-darwin24/sys-include   -fno-checking
:info:build checking for suffix of object files... configure: error: in `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc14/libgcc14/work/build/aarch64-apple-darwin24/libgcc':
:info:build configure: error: cannot compute suffix of object files: cannot compile

[cjones051073 (Chris Jones)]

You have not provided enough information for anyone to help. Please provide a complete build log. First though ensure you are up to date with

sudo port sync
sudo port upgrade outdafed

[EvilJordan (Jordan Holberg)]

Replying to cjones051073:

You have not provided enough information for anyone to help. Please provide a complete build log. First though ensure you are up to date with

sudo port sync
sudo port upgrade outdafed

This was exactly what I needed. I'm a DUMMY and forgot to sync/update the local repos before trying to install the port again. DUH. I got lost in the weeds and forgot the basics. THANK YOU!

[fxcoudert (FX Coudert)]

The Intel-only macOS 15 bug in building libgcc_s.1.dylib is ​https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809

[markmentovai (Mark Mentovai)]

I forked the libgcc_s.1.dylib bug to #70866 for MacPorts tracking purposes. Upstream discussion of that bug is indeed at ​https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809.

[markemer (Mark Anderson)]

Can we remove configurepipe no?

[markmentovai (Mark Mentovai)]

configurepipe no never landed in macports-ports. If you added it locally, you can remove it now.