libgcc12 @12.3.0: ld: library not found for -ld_classic

[k6wx (Kristen McIntyre)]

As the summary says, libgcc, which is a dependency for emacs, fails with "library not found for -ld_classic" on macOS Sonoma. I can reproduce this every time from what I believe is a clean install (rm -rf /opt/local) by attempting to install emacs.

[k6wx (Kristen McIntyre)]

Log file from the build.

[cjones051073 (Chris Jones)]

Somehow it seems you have Xcode 15 installed but your system doesn't seem to understand the ld_classic option. Not sure how that can be really. Please run

xcrun -v ld -ld_classic -v

and post the output here.

[k6wx (Kristen McIntyre)]

Here you go.

[Kristens-MBP:/] kristen% xcrun -v ld -ld_classic -v
xcrun: note: looking up SDK with '/Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild -sdk /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -version PlatformPath'
xcrun: note: PATH = '/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:.:/Users/kristen/bin:/usr/local/bin:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/opt/X11/bin:/Library/Apple/usr/bin:/usr/X11R6/bin:/opt/local/bin:/opt/local/sbin'
xcrun: note: SDKROOT = '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk'
xcrun: note: TOOLCHAINS = ''
xcrun: note: DEVELOPER_DIR = '/Applications/Xcode.app/Contents/Developer'
xcrun: note: XCODE_DEVELOPER_USR_PATH = ''
xcrun: note: xcrun_db = '/var/folders/n5/9cztlzh91jd3tyl21m91ypsr0000gn/T/xcrun_db'
xcrun: note: lookup resolved to: '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform'
xcrun: note: database key is: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk|/Applications/Xcode.app/Contents/Developer|<manpath>
xcrun: note: PATH = '/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:.:/Users/kristen/bin:/usr/local/bin:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/opt/X11/bin:/Library/Apple/usr/bin:/usr/X11R6/bin:/opt/local/bin:/opt/local/sbin'
xcrun: note: SDKROOT = '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk'
xcrun: note: TOOLCHAINS = ''
xcrun: note: DEVELOPER_DIR = '/Applications/Xcode.app/Contents/Developer'
xcrun: note: XCODE_DEVELOPER_USR_PATH = ''
xcrun: note: xcrun_db = '/var/folders/n5/9cztlzh91jd3tyl21m91ypsr0000gn/T/xcrun_db'
xcrun: note: xcrun via ld (xcrun)
xcrun: note: database key is: ld|/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk||/Applications/Xcode.app/Contents/Developer|
xcrun: note: looking up with '/Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild -sdk /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -find ld 2> /dev/null'
xcrun: note: lookup resolved with 'xcodebuild -find' to '/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld'
@(#)PROGRAM:ld  PROJECT:dyld-1015.7
BUILD 18:48:43 Aug 22 2023
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em
will use ld-classic for: armv6 armv7 armv7s arm64_32 i386 armv6m armv7k armv7m armv7em
LTO support using: LLVM version 15.0.0 (static support for 29, runtime is 29)
TAPI support using: Apple TAPI version 15.0.0 (tapi-1500.0.12.3)
Library search paths:
Framework search paths:
[Kristens-MBP:/] kristen% 

[cjones051073 (Chris Jones)]

Hm, interesting. So you are on an Intel system... I am a bit concerned by the line

will use ld-classic for: armv6 armv7 armv7s arm64_32 i386 armv6m armv7k armv7m armv7em

that appears to imply ld-classic is not available x86_64, which would be very odd indeed...

[cjones051073 (Chris Jones)]

I cannot reproduce ld_classic not working for x86_64 on my arm system here (Xcode15 macOS13)

> clang++ -std=c++17 -O3 -Wl,-ld_classic -o a.arm64.out ./test.cpp
> arch -x86_64 clang++ -std=c++17 -O3 -Wl,-ld_classic -o a.x86_64.out ./test.cpp
> file a.*.out     
a.arm64.out:  Mach-O 64-bit executable arm64
a.x86_64.out: Mach-O 64-bit executable x86_64

Please try the above with the test file I will attach next..

[k6wx (Kristen McIntyre)]

[Kristens-MBP:~/tmp] kristen% clang++ -std=c++17 -O3 -Wl,-ld_classic -o a.arm64.out ./test.cpp
[Kristens-MBP:~/tmp] kristen% arch -x86_64 clang++ -std=c++17 -O3 -Wl,-ld_classic -o a.x86_64.out ./test.cpp
[Kristens-MBP:~/tmp] kristen% file a.*.out
a.arm64.out:  Mach-O 64-bit executable x86_64
a.x86_64.out: Mach-O 64-bit executable x86_64

[cjones051073 (Chris Jones)]

OK, so yes the second command using arch was not needed as your system is anyway x86_64.

But then this seems at odds with what your log above reports. -ld_classic worked just fine in the above simple tests.

I'm afraid I cannot really explain this...

[Dave-Allured (Dave Allured)]

From main.log, the active command on the error is "xgcc". This has hidden the exact context of -ld_classic. However, past experience is that you have something like this underneath "xgcc":

gcc -ld_classic

I think this is processed at the wrong time, so it is interpreted as a library request rather than a linker option. This would explain "library not found". Probably you want the following instead. See option -Wl in GCC docs, "Options for Linking".

gcc -Wl,-ld_classic

[cjones051073 (Chris Jones)]

Thing is, the port file does not do anything with these linker options, we just tell the gcc build to use a linker than enforces the classic linker.

​https://github.com/macports/macports-ports/blob/master/lang/gcc12/Portfile#L176

Its up to the gcc build to use that correctly.

There is nothing we need or can do on the port side to change how the flag is handled.

Also, the workaround works just fine for many other users on similar systems. So I still don't get what is going on in this case to cause it.

[Dave-Allured (Dave Allured)]

Okay. It looks like you are telling gcc to use the classic linker in two different ways at the same time.

--with-ld=${prefix}/bin/ld-classic

and

-ld_classic

Now here is the fun part. My guess is that the old linker ld-classic does not include the special option -ld_classic. You can specify either the executable or the switch option, but not both at the same time.

[cjones051073 (Chris Jones)]

sorry, but please point to specifically where in the Profile we are "telling gcc to use the classic linker in two different ways at the same time." ?

[cjones051073 (Chris Jones)]

​https://github.com/macports/macports-ports/blob/master/lang/gcc12/Portfile#L176

That is the only place in the port file where the term classic appears.

So no, we aren't telling gcc two different ways to use the classic linker.

[Dave-Allured (Dave Allured)]

Yes indeed the reported build is telling gcc two different ways at the same time.

--with-ld=${prefix}/bin/ld-classic is in that portfile, currently line 176.

-ld_classic is an option on the compiler command line, and is coming from somewhere else. I don't know where, but something is definitely injecting that. Perhaps a portgroup or the latest source for libgcc12. I do not have all the answers instantly for you, but this nicely explains the reported error message.

[Dave-Allured (Dave Allured)]

In main.log, the operative command at the error is xgcc. I do not know how to examine the complete expansion of xgcc, but my guess is that it includes --with-ld=${prefix}/bin/ld-classic. If you can confirm that, this would prove that the two different options are both applied in the same command.

[kencu (Ken)]

try fixing this issue first:

:warn:clean The Command Line Tools may be outdated, which can cause problems.
:warn:clean Please see: <https://trac.macports.org/wiki/ProblemHotlist#reinstall-clt>

and see if that fixes you up.

[cjones051073 (Chris Jones)]

Replying to Dave-Allured:

In main.log, the operative command at the error is xgcc. I do not know how to examine the complete expansion of xgcc, but my guess is that it includes --with-ld=${prefix}/bin/ld-classic. If you can confirm that, this would prove that the two different options are both applied in the same command.

xgcc is an internal temporary compiler built by gcc as part of its boot strap process. I cannot check anything w.r.t. it.

Anyway, I think your suggestion here is off the mark. I more suspect the issue is what Ken spotted, as that explains why only the OP here sees the problem.

[Dave-Allured (Dave Allured)]

Maybe. However, in main.log line 5:

:debug:sysinfo Xcode 15.0, CLT none

So where is "The Command Line Tools may be outdated" coming from?

[cjones051073 (Chris Jones)]

I cannot say what is causing the warning, but its there in the log file.

If the CLT is not installed at all, that might also be a reason as I am now wondering if the ld_classic option only works via the CLT..

In either case, Kristen, please ensure you both have the CLT installed, and it is up to date. Then try again and if it still fails post the complete log file again.

[Dave-Allured (Dave Allured)]

Kristen, are you also using another packager such as Homebrew or Conda to install anything? Also yes, please try Chris's last suggestion to install CLT 15.0 and try again.

[jmroot (Joshua Root)]

Replying to Dave-Allured:

Maybe. However, in main.log line 5:

:debug:sysinfo Xcode 15.0, CLT none

So where is "The Command Line Tools may be outdated" coming from?

Ken didn't quote one of the relevant lines:

:warn:clean The Xcode Command Line Tools package appears to be installed, but its receipt appears to be missing.

none is the CLT version that is detected, because finding the version (for MacPorts as well as Software Update) relies on the receipt existing.

[Dave-Allured (Dave Allured)]

Okay. It looks like -ld_classic is coming from here: ​https://github.com/macports/macports-ports/commit/32bc043e582c33a4636fee958774739e7cb90e5b

And --with-ld=${prefix}/bin/ld-classic comes from the current gcc12 Portfile. The result is that the two are effectively combined in the same xgcc command, which results in this error. Chris?

[k6wx (Kristen McIntyre)]

No other packager is in use. I will try to update the CLT a little later today.

[cjones051073 (Chris Jones)]

Replying to Dave-Allured:

Okay. It looks like -ld_classic is coming from here: ​https://github.com/macports/macports-ports/commit/32bc043e582c33a4636fee958774739e7cb90e5b

And --with-ld=${prefix}/bin/ld-classic comes from the current gcc12 Portfile. The result is that the two are effectively combined in the same xgcc command, which results in this error. Chris?

Incorrect. That commit is simply adding support to the ld64 port, adding the ${prefix}/bin/ld-classic wrapper, which then gcc12 just uses via the configuration option.

[Dave-Allured (Dave Allured)]

Okay. All I can say now is that command option -ld_classic passed to any older version of the Xcode linker by any mechanism, has an exact explanation for "library not found". -ld_classic is being misinterpreted as a library request of the form -l${short_lib_name}. Linker looks for libd_classic.dylib and does not find it. This might not be the right explanation, but it is likely.

Kristen, I suggest that in addition to updating your CLT, also port selfupdate before testing again.

[cjones051073 (Chris Jones)]

Replying to Dave-Allured:

Okay. All I can say now is that command option -ld_classic passed to any older version of the Xcode linker by any mechanism, has an exact explanation for "library not found". -ld_classic is being misinterpreted as a library request of the form -l${short_lib_name}. Linker looks for libd_classic.dylib and does not find it. This might not be the right explanation, but it is likely.

No it is not. The -ld_classic option is only used by gcc when the user is running macOS13 or newer, and then only when they also have Xcode15 or newer.

​https://github.com/macports/macports-ports/blob/master/lang/gcc12/Portfile#L168

Honestly, this is IMHO not where the problem lies.

Kristen, I suggest that in addition to updating your CLT, also port selfupdate before testing again.

This for me is the far more likely reason, as it also explains why the issue doesn't seem to affect others. The configuration gcc12 has to work around the Xcode15 issues have been used just fine in a number of other places so far.

[k6wx (Kristen McIntyre)]

Updating the CLT and doing 'port selfupdate' did the trick. It took a long while to finish building everything, but it did finish successfully and emacs executes correctly.

I hope this wasn't just noise and provided some useful feedback. Thank you to all of you for your help with this.

--->  Attempting to fetch emacs-29.1.tar.gz from http://mirror.facebook.net/gnu/emacs
--->  Verifying checksums for emacs                                                  
--->  Extracting emacs
--->  Configuring emacs
--->  Building emacs                                     
--->  Staging emacs into destroot                        
--->  Installing emacs @29.1_2+nativecomp+treesitter     
--->  Activating emacs @29.1_2+nativecomp+treesitter
--->  Cleaning emacs
--->  Updating database of binaries
--->  Scanning binaries for linking errors
--->  No broken files found.                             
--->  No broken ports found.