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.

[ar-an-ribe]

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.

[ar-an-ribe]

main.log for gcc13 @13.2.0_4 +stdlib_flag+universal

[ar-an-ribe]

config.log for configuration stage 1 of intl

[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.

[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?

[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—VersionTuples 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.

[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.

[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).

[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.

[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.

[kencu (Ken)]

Let's see how to most efficiently sort you out....

[kencu (Ken)]

If you do this:

sudo port -v deactivate ld64

sudo port -v installl 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.

[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.

[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.

[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 installed ld64 and ld64-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.

[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.

[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?

[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.

[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!

[kencu (Ken)]

thanks!