Opened 5 months ago
Closed 5 months ago
#70227 closed defect (worksforme)
gcc13 @13.2.0_4 +stdlib_flag+universal: configuration stage 1 of intl fails on 10.9 Mavericks when the linker has been manually set to ld64-xcode.
Reported by: | ar-an-ribe | Owned by: | |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.9.3 |
Keywords: | Cc: | ||
Port: | gcc13 |
Description
In trying to build gcc13 @13.2.0_4 +stdlib_flag+universal
on Mavericks, the configuration stage 1 for building intl
fails:
:info:build checking for x86_64-apple-darwin13-gcc... /opt/local/bin/clang-mp-16 -arch i386 -arch x86_64 :info:build no :info:build configure: error: in `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc13/gcc13/work/build/intl': :info:build configure: error: C compiler cannot create executables :info:build See `config.log' for more details :info:build make[2]: *** [configure-stage1-intl] Error 77 :info:build make[2]: *** Waiting for unfinished jobs....
The relevant lines from intl
’s config.log
seem to be:
configure:2569: checking whether the C compiler works configure:2591: /opt/local/bin/clang-mp-16 -arch i386 -arch x86_64 -g -L/opt/local/lib -Wl,-headerpad_max_install_names conftest.c >&5 ld: unknown option: -no_deduplicate clang: error: linker command failed with exit code 1 (use -v to see invocation) configure:2595: $? = 1 configure:2633: result: no configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "" | #define PACKAGE_TARNAME "" | #define PACKAGE_VERSION "" | #define PACKAGE_STRING "" | #define PACKAGE_BUGREPORT "" | #define PACKAGE_URL "" | /* end confdefs.h. */ | | int | main () | { | | ; | return 0; | } configure:2638: error: in `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc13/gcc13/work/build/intl': configure:2640: error: C compiler cannot create executables
This seems to be another ticket that is related to ld
.
Attachments (2)
Change History (20)
Changed 5 months ago by ar-an-ribe
Changed 5 months ago by ar-an-ribe
Attachment: | config.log added |
---|
config.log for configuration stage 1 of intl
comment:1 Changed 5 months ago by ar-an-ribe
The relevant ld
line that was shown in the .CC_PRINT_OPTIONS
file looks like
"/opt/local/libexec/llvm-16/bin/ld" "-demangle" "-lto_library" "/opt/local/libexec/llvm-16/lib/libLTO.dylib" "-no_deduplicate" "-dynamic" "-arch" "i386" "-macosx_version_min" "10.9.0" "-o" "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc13/gcc13/work/.tmp/conftest-db012a/conftest-i386.out" "-L/opt/local/lib" "-L/opt/local/lib" "-headerpad_max_install_names" "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc13/gcc13/work/.tmp/conftest-6a2f8a/conftest-i386.o" "-lSystem" "/opt/local/libexec/llvm-16/lib/clang/16/lib/darwin/libclang_rt.osx.a"
when trying to link conftest-i386.out
using /opt/local/libexec/llvm-16/bin/ld
.
comment:2 Changed 5 months ago by ar-an-ribe
On my computer, /opt/local/libexec/llvm-16/bin/ld
is a shell script that calls /usr/bin/xcrun ld "${@}"
because /usr/bin/xcrun
is executable on it.
The particular ld
executable is revealed by xcrun --find ld
, which turns out to be /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld
.
The version of this ld
executable is revealed by $(xcrun --find ld) -v
, which turns out to be
@(#)PROGRAM:ld PROJECT:ld64-236.4 configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 armv6m armv7m armv7em LTO support using: LLVM version 3.4svn
I presume that the -no_deduplicate
option of ld
is not supported in this ld64-236.4
version of ld
?
comment:3 Changed 5 months ago by ar-an-ribe
The -no_deduplicate
option is indeed unrecognized by the ld64-236.4
version of ld
.
This option is most likely being added through llvm
, represented in this ticket by clang-mp-16
.
In the source for llvm-15 @15.0.7_0
, this option is added to the command line depending upon the result of the shouldLinkerNotDedup
() static function of clang/lib/Driver/ToolChains/Darwin.cpp
. Support for this option in ld64
must have been added after version 236.4 and before version 262, since a comment in the darwin::Linker::AddLinkArgs
() function in the same file notes that this option is added automatically starting with version 262 of ld64
.
Presuming that this file’s code is similar in other versions of llvm
as well, the darwin::Linker::AddLinkArgs
() function in this file should be patched so that the -no_deduplicate
option is not “pushed back” into the command arguments when Version <= VersionTuple(236)
(if I’ve understood that code correctly—VersionTuple
s are used for more things in this code than just the ld64
version). If versions of Xcode ld64
on releases of macOS that are newer than Mavericks also don’t recognize the -no_deduplicate
option, then that “236” value in the VersionTuple
comparison should be increased to match the latest ld64
version that lacks support for the -no_deduplicate
option.
comment:4 follow-up: 5 Changed 5 months ago by kencu (Ken)
can I ask you for the results of the following please:
port -v installed | grep active | grep ld64 port -v installed | grep active | grep cctools
thanks.
comment:5 Changed 5 months ago by ar-an-ribe
Replying to kencu:
can I ask you for the results of the following please:
port -v installed | grep active | grep ld64 port -v installed | grep active | grep cctools
They’re
ld64 @3_6+ld64_xcode+universal (active) requested_variants='+ld64_xcode+universal' platform='darwin 13' archs='i386 x86_64' date='2023-09-28T15:03:34-0400' ld64-latest @450.3_0+llvm80+universal (active) requested_variants='+llvm80+universal' platform='darwin 13' archs='i386 x86_64' date='2020-02-07T17:09:44-0500' ld64-xcode @2_6+universal (active) requested_variants='+universal' platform='darwin 13' archs='i386 x86_64' date='2023-09-28T15:03:32-0400'
and
cctools @949.0.1_3+llvm13+universal (active) requested_variants='+llvm13+universal' platform='darwin 13' archs='i386 x86_64' date='2023-05-05T14:07:27-0400'
respectively (with leading spaces removed).
comment:6 follow-up: 11 Changed 5 months ago by kencu (Ken)
mine (on my 10.9 VM) look like this:
$ port -v installed | grep active | grep ld64 ld64 @3_6+ld64_274+universal (active) requested_variants='+universal' platform='darwin 13' archs='i386 x86_64' date='2024-06-15T13:43:45-0700' ld64-274 @274.2_0+llvm37+universal (active) requested_variants='+universal' platform='darwin 13' archs='i386 x86_64' date='2024-06-15T13:43:45-0700' $ port -v installed | grep active | grep cctools cctools @949.0.1_3+llvm37+universal (active) requested_variants='+universal' platform='darwin 13' archs='i386 x86_64' date='2024-06-15T14:17:05-0700'
On your older system, /opt/local/libexec/llvm-16/bin/ld
is not supposed to be a shell script that calls /usr/bin/xcrun ld "${@}".
It is supposed to be a symlink that points to /opt/local/libexec/ld64/ld
which is supposed to be a symlink to a newer linker.
comment:7 Changed 5 months ago by kencu (Ken)
OK -- so your system has indeed become misconfigured. Looks like you've played around a bit with the linkers, and now you're actually calling the extremely ancient linker in Xcode, which on that system is very ancient indeed, ergo all your errors.
comment:9 Changed 5 months ago by kencu (Ken)
If you do this:
sudo port -v deactivate ld64 sudo port -v install ld64 -ld64_274
you should get a setup that makes your active linker ld64-latest, which is still non-default, but should work out a LOT better for you as it is much newer than that old dog linker in Xcode.
comment:10 follow-up: 17 Changed 5 months ago by kencu (Ken)
Once you can confirm that using a current linker indeed fixes up all your recent build errors, we can close out the recent tickets you opened. Please get back to us with the info about that so we can clean up Trac a bit.
comment:11 follow-up: 12 Changed 5 months ago by ar-an-ribe
Replying to kencu:
On your older system,
/opt/local/libexec/llvm-16/bin/ld
is not supposed to be a shell script that calls /usr/bin/xcrun ld "${@}".It is supposed to be a symlink that points to
/opt/local/libexec/ld64/ld
which is supposed to be a symlink to a newer linker.
I apologize for my lack of precision. On my computer, /opt/local/libexec/llvm-16/bin/ld
is indeed a symbolic link that points to /opt/local/libexec/ld64/ld
, and it is the latter that calls /usr/bin/xcrun ld "${@}"
. The last-modification date of /opt/local/libexec/ld64/ld
is 2023-09-28, which corresponds to the dates of the installed ld64
and ld64-xcode
ports.
comment:12 Changed 5 months ago by kencu (Ken)
Replying to ar-an-ribe:
I apologize for my lack of precision. On my computer,
/opt/local/libexec/llvm-16/bin/ld
is indeed a symbolic link that points to/opt/local/libexec/ld64/ld
, and it is the latter that calls/usr/bin/xcrun ld "${@}"
. The last-modification date of/opt/local/libexec/ld64/ld
is 2023-09-28, which corresponds to the dates of the installedld64
andld64-xcode
ports.
Yes I know, but:
you don't want ld64-xcode, as it is extremely OLD and causing all your errors.
you want ld64-274 or better ld64-latest to be your active linker.
The steps I outlined should get you there.
comment:13 follow-up: 15 Changed 5 months ago by kencu (Ken)
by the way, you may find cctools may not work properly all the time with llvm13 backing it.
the calling conventions changed a bit after llvm10 (IIRC), and some scripts will generate errors, you may find.
comment:14 Changed 5 months ago by kencu (Ken)
Summary: | gcc13 @13.2.0_4 +stdlib_flag+universal: configuration stage 1 of intl fails → gcc13 @13.2.0_4 +stdlib_flag+universal: configuration stage 1 of intl fails on 10.9 Mavericks when the linker has been manually set to ld64-xcode. |
---|
comment:15 Changed 5 months ago by ar-an-ribe
Replying to kencu:
by the way, you may find cctools may not work properly all the time with llvm13 backing it.
the calling conventions changed a bit after llvm10 (IIRC), and some scripts will generate errors, you may find.
Would any of the +llvm14
through +llvm16
variants be a better choice for cctools
, or is that just a feature of any variant after +llvm10
?
comment:16 Changed 5 months ago by kencu (Ken)
the llvm command line utilities, like llvm-ar, changed their syntax, to no longer accept single-dash options.
I think that was after llvm-10 (11+), but I can’t find the commit just now that did it to prove that.
comment:17 Changed 5 months ago by ar-an-ribe
Replying to kencu:
Once you can confirm that using a current linker indeed fixes up all your recent build errors, we can close out the recent tickets you opened. Please get back to us with the info about that so we can clean up Trac a bit.
Per your recommendation in comment #9, I’d deactivated ld64 @3_6 +ld64_xcode+universal
and installed ld64 @3_6 -ld64_274+universal
in its place. The gcc13 @13.2.0_4 +stdlib_flag+universal
port now compiles without the failure in configuration stage 1 in intl
; it’ll take a while longer to see if it will also resolve #70206.
Thank you for the recommendation!
comment:18 Changed 5 months ago by kencu (Ken)
Resolution: | → worksforme |
---|---|
Status: | new → closed |
thanks!
main.log for gcc13 @13.2.0_4 +stdlib_flag+universal