Opened 2 months ago

Closed 7 weeks ago

Last modified 5 weeks ago

#70641 closed defect (fixed)

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)

Reported by: avisformosa Owned by:
Priority: Normal Milestone:
Component: ports Version: 2.10.1
Keywords: sequoia Cc: razzfazz (Daniel Becker), amake (Aaron Madlon-Kay), cjones051073 (Chris Jones), alexleigh (Alex Leigh), ATL-Flaneur (Andreas Yankopolus), markmentovai (Mark Mentovai), wdormann, haberg-1 (Hans Åberg), EvilJordan (Jordan Holberg), Bradford-Miller (Bradford Miller), mamoll (Mark Moll), reneeotten (Renee Otten), cooljeanius (Eric Gallager)
Port: libgcc14 gcc14

Description (last modified by jmroot (Joshua Root))

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!

Attachments (3)

main.log (5.5 MB) - added by avisformosa 2 months ago.
Main log libgcc14 - due to size in two parts
main2.log (6.0 MB) - added by avisformosa 2 months ago.
Main log libgcc14 - due to size in two parts
config.log (40.6 KB) - added by avisformosa 2 months ago.
config log from port work libgcc14

Change History (64)

comment:1 Changed 2 months ago by jmroot (Joshua Root)

Description: modified (diff)
Keywords: sequoia added; libgcc14 removed

comment:2 Changed 2 months ago by 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.

comment:3 Changed 2 months ago by ryandesign (Ryan Carsten Schmidt)

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

Changed 2 months ago by avisformosa

Attachment: main.log added

Main log libgcc14 - due to size in two parts

Changed 2 months ago by avisformosa

Attachment: main2.log added

Main log libgcc14 - due to size in two parts

Changed 2 months ago by avisformosa

Attachment: config.log added

config log from port work libgcc14

comment:4 Changed 2 months ago by 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

comment:5 Changed 2 months ago by 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.

comment:6 Changed 2 months ago by ryandesign (Ryan Carsten Schmidt)

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

comment:7 Changed 2 months ago by oversized-monday (MONDAY!)

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

comment:8 Changed 2 months ago by markemer (Mark Anderson)

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

comment:9 Changed 8 weeks ago by razzfazz (Daniel Becker)

Cc: razzfazz added

comment:10 Changed 7 weeks ago by 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
Last edited 7 weeks ago by amake (Aaron Madlon-Kay) (previous) (diff)

comment:11 Changed 7 weeks ago by amake (Aaron Madlon-Kay)

Cc: amake added

comment:12 Changed 7 weeks ago by 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.

Last edited 7 weeks ago by snowflake (Dave Evans) (previous) (diff)

comment:13 Changed 7 weeks ago by amake (Aaron Madlon-Kay)

Emacs users can successfully build by disabling the nativecomp variant.

comment:14 Changed 7 weeks ago by amake (Aaron Madlon-Kay)

(accidental double-post)

Last edited 7 weeks ago by amake (Aaron Madlon-Kay) (previous) (diff)

comment:15 Changed 7 weeks ago by theChachi (Sam Bizzell)

Cc: theChachi added

comment:16 Changed 7 weeks ago by 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.

Last edited 7 weeks ago by cjones051073 (Chris Jones) (previous) (diff)

comment:17 Changed 7 weeks ago by cjones051073 (Chris Jones)

Cc: cjones051073 added

comment:18 Changed 7 weeks ago by 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.

comment:19 Changed 7 weeks ago by 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.

comment:20 Changed 7 weeks ago by markmentovai (Mark Mentovai)

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

comment:21 Changed 7 weeks ago by alexleigh (Alex Leigh)

Cc: alexleigh added

comment:22 in reply to:  13 Changed 7 weeks ago by 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.

comment:23 Changed 7 weeks ago by 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

Last edited 7 weeks ago by BarneyStratford (previous) (diff)

comment:24 Changed 7 weeks ago by 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.

Last edited 7 weeks ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:25 Changed 7 weeks ago by ATL-Flaneur (Andreas Yankopolus)

Cc: ATL-Flaneur added

comment:26 Changed 7 weeks ago by 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

Last edited 7 weeks ago by dbl001 (dbl) (previous) (diff)

comment:27 Changed 7 weeks ago by markmentovai (Mark Mentovai)

Cc: markmentovai added

comment:28 Changed 7 weeks ago by wdormann

Cc: wdormann added

comment:29 Changed 7 weeks ago by theChachi (Sam Bizzell)

Cc: theChachi removed

comment:30 Changed 7 weeks ago by 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.

comment:31 Changed 7 weeks ago by cjones051073 (Chris Jones)

Port: gcc14 added

comment:32 Changed 7 weeks ago by haberg-1 (Hans Åberg)

Cc: haberg-1 added

comment:33 Changed 7 weeks ago by 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

comment:34 in reply to:  26 Changed 7 weeks ago by 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.

comment:35 Changed 7 weeks ago by 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

comment:36 Changed 7 weeks ago by EvilJordan (Jordan Holberg)

Cc: EvilJordan added

comment:37 Changed 7 weeks ago by Bradford-Miller (Bradford Miller)

Cc: Bradford-Miller added

comment:38 Changed 7 weeks ago by mamoll (Mark Moll)

Cc: mamoll added

comment:39 Changed 7 weeks ago by 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?

Last edited 7 weeks ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:40 Changed 7 weeks ago by markmentovai (Mark Mentovai)

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

comment:41 Changed 7 weeks ago by markmentovai (Mark Mentovai)

comment:42 in reply to:  39 Changed 7 weeks ago by 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.

Last edited 7 weeks ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:43 Changed 7 weeks ago by 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

comment:44 Changed 7 weeks ago by reneeotten (Renee Otten)

Cc: reneeotten added

comment:45 in reply to:  43 Changed 7 weeks ago by 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.

comment:46 Changed 7 weeks ago by cjones051073 (Chris Jones)

Resolution: fixed
Status: newclosed

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

comment:47 Changed 7 weeks ago by 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

comment:48 Changed 7 weeks ago by 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.

comment:49 Changed 7 weeks ago by 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.

Last edited 7 weeks ago by cjones051073 (Chris Jones) (previous) (diff)

comment:50 Changed 7 weeks ago by haberg-1 (Hans Åberg)

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

comment:51 in reply to:  47 Changed 7 weeks ago by 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.

comment:52 Changed 7 weeks ago by 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.

comment:53 Changed 7 weeks ago by cjones051073 (Chris Jones)

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

comment:54 in reply to:  49 Changed 7 weeks ago by 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

comment:55 Changed 7 weeks ago by cooljeanius (Eric Gallager)

Cc: cooljeanius added

comment:56 Changed 7 weeks ago by 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

comment:57 in reply to:  56 Changed 7 weeks ago by 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!

comment:58 Changed 7 weeks ago by 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

comment:59 Changed 7 weeks ago by 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.

Last edited 7 weeks ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:60 Changed 5 weeks ago by markemer (Mark Anderson)

Can we remove configurepipe no?

comment:61 Changed 5 weeks ago by markmentovai (Mark Mentovai)

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

Note: See TracTickets for help on using tickets.