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