Opened 3 weeks ago
Last modified 7 hours ago
#70641 new defect
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, EvilJordan (Jordan Holberg), Bradford-Miller (Bradford Miller) |
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 (40)
comment:1 Changed 3 weeks ago by jmroot (Joshua Root)
Description: | modified (diff) |
---|---|
Keywords: | sequoia added; libgcc14 removed |
comment:2 Changed 2 weeks ago by oversized-monday (MONDAY!)
comment:3 Changed 2 weeks ago by ryandesign (Ryan Carsten Schmidt)
Please attach the main.log and config.log files.
Changed 2 weeks ago by avisformosa
Main log libgcc14 - due to size in two parts
Changed 2 weeks ago by avisformosa
Main log libgcc14 - due to size in two parts
comment:4 Changed 2 weeks 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 weeks 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 weeks 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 13 days 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 8 days 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 3 days ago by razzfazz (Daniel Becker)
Cc: | razzfazz added |
---|
comment:10 Changed 3 days 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 3 days ago by amake (Aaron Madlon-Kay)
Cc: | amake added |
---|
comment:12 Changed 3 days 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 3 days ago by amake (Aaron Madlon-Kay)
Emacs users can successfully build by disabling the nativecomp
variant.
comment:15 Changed 3 days ago by theChachi (Sam Bizzell)
Cc: | theChachi added |
---|
comment:16 Changed 3 days 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 3 days ago by cjones051073 (Chris Jones)
Cc: | cjones051073 added |
---|
comment:18 Changed 3 days 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 3 days 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 2 days 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 2 days ago by alexleigh (Alex Leigh)
Cc: | alexleigh added |
---|
comment:22 Changed 44 hours 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 38 hours 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 36 hours 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 34 hours ago by ATL-Flaneur (Andreas Yankopolus)
Cc: | ATL-Flaneur added |
---|
comment:26 follow-up: 34 Changed 34 hours 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 34 hours ago by markmentovai (Mark Mentovai)
Cc: | markmentovai added |
---|
comment:28 Changed 32 hours ago by wdormann
Cc: | wdormann added |
---|
comment:29 Changed 31 hours ago by theChachi (Sam Bizzell)
Cc: | theChachi removed |
---|
comment:30 Changed 30 hours 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 28 hours ago by cjones051073 (Chris Jones)
Port: | gcc14 added |
---|
comment:32 Changed 20 hours ago by haberg-1
Cc: | haberg-1 added |
---|
comment:33 Changed 15 hours 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 14 hours 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 12 hours 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 12 hours ago by EvilJordan (Jordan Holberg)
Cc: | EvilJordan added |
---|
comment:37 Changed 7 hours ago by Bradford-Miller (Bradford Miller)
Cc: | Bradford-Miller added |
---|
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.