#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)
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!)
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
Main log libgcc14 - due to size in two parts
Changed 2 months ago by avisformosa
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:
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
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.
comment:13 follow-up: 22 Changed 7 weeks ago by amake (Aaron Madlon-Kay)
Emacs users can successfully build by disabling the nativecomp
variant.
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.
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 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
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.
comment:25 Changed 7 weeks ago by ATL-Flaneur (Andreas Yankopolus)
Cc: | ATL-Flaneur added |
---|
comment:26 follow-up: 34 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
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 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 follow-up: 42 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?
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)
Upstream GCC fix landed (so far only on trunk): https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=33ccc1314dcdb0b988a9276ca6b6ce9b07bea21e
comment:42 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.
comment:43 follow-up: 45 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 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: | new → closed |
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 follow-up: 51 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 follow-up: 54 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.
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 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 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 follow-up: 57 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 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 https://trac.macports.org/ticket/70866 for MacPorts tracking purposes. Upstream discussion of that bug is indeed at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809.
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.
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.