libgcc11 11.3.0 update has removed libgcc_ext.10.[4-5].dylib

[Serge3leo (Serguei E. Leontiev)]

Clean install gcc9 (macOS Catalina 10.15.7 (19H1824), Xcode 12.4 (12D4e))

$ ls -lL `port contents gcc9 | sed -e 1d` > /dev/null
ls: libgcc_ext.10.4.dylib: No such file or directory
ls: libgcc_ext.10.5.dylib: No such file or directory
$ LANG=C ls -lL /opt/local/lib/gcc9/libgcc_ext.10.*
lrwxr-xr-x  1 root  admin  43 Dec 26 00:47 /opt/local/lib/gcc9/libgcc_ext.10.4.dylib -> /opt/local/lib/libgcc/libgcc_ext.10.4.dylib
lrwxr-xr-x  1 root  admin  43 Dec 26 00:47 /opt/local/lib/gcc9/libgcc_ext.10.5.dylib -> /opt/local/lib/libgcc/libgcc_ext.10.5.dylib
ls: libgcc_ext.10.4.dylib: No such file or directory
ls: libgcc_ext.10.5.dylib: No such file or directory

$ port installed requested
The following ports are currently installed:
  gcc9 @9.4.0_1 (active)

$ port installed
The following ports are currently installed:
  cctools @949.0.1_2+xcode (active)
  gcc9 @9.4.0_1 (active)
  gcc_select @0.1_9 (active)
  gettext-runtime @0.21_0 (active)
  gmp @6.2.1_1 (active)
  isl @0.24_1 (active)
  ld64 @3_4+ld64_xcode (active)
  ld64-xcode @2_4 (active)
  libgcc @5.0_0 (active)
  libgcc9 @9.4.0_0 (active)
  libgcc10 @10.3.0_3 (active)
  libgcc11 @11.3.0_0 (active)
  libiconv @1.16_1 (active)
  libmpc @1.2.1_0 (active)
  mpfr @4.1.0_0 (active)
  xz @5.2.5_1 (active)
  zlib @1.2.12_0 (active)

Build failed of simple program:

$ gfortran-mp-9 ref-hello_world.f
ld: library not found for -lgcc_ext.10.5
collect2: error: ld returned 1 exit status

[Serge3leo (Serguei E. Leontiev)]

Workaround:

$ sudo port build gcc9
...
$ sudo cp /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc9/gcc9/work/build/x86_64-apple-darwin19/libgcc/libgcc_ext.10.[45].dylib /opt/local/lib/libgcc/.

[kencu (Ken)]

could you undo your workarounds and try this, so we can see what is happening here exactly?

Thanks!

gfortran-mp-9 -v -Wl,-v ref-hello_world.f

[johnrosshunt]

Same problem for me on Catalina with GCC-10. GCC-11 works fine, however.

[kencu (Ken)]

So the gcc10 log shows it is looking here:

/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk

but some time ago I changed our gcc versions to use MacOSX.sdk instead to prevent this, and revbumped them all to pick up the new SDK location:

​https://github.com/macports/macports-ports/commit/e8866c5019d60832527850b4e50fdc1de8878716

​https://github.com/macports/macports-ports/blob/e2fcb06f9ed05f310a1abf7b9cbc31c61f908d7a/lang/gcc10/Portfile#L177

So they should be built to look here:

/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk

I wonder what is wrong with this plan?

[kencu (Ken)]

actually I will revert that until we hear back from the gcc9 reporter

[johnrosshunt]

On my Catalina system, that points to the Xcode SDK:

Catalina:

$ ls -las /Library/Developer/CommandLineTools/SDKs/
total 0
0 drwxr-xr-x  7 root  wheel  224 Mar 14 21:59 .
0 drwxr-xr-x  5 root  wheel  160 Nov 11  2019 ..
0 lrwxr-xr-x  1 root  wheel   14 Mar 14 21:58 MacOSX.sdk -> MacOSX11.1.sdk
0 drwxr-xr-x  7 root  wheel  224 Sep  2  2020 MacOSX10.14.sdk
0 drwxr-xr-x  8 root  wheel  256 Mar 14 21:59 MacOSX10.15.sdk
0 drwxr-xr-x  4 root  wheel  128 Dec 14  2020 MacOSX11.0.sdk
0 drwxr-xr-x  7 root  wheel  224 Mar 14 21:59 MacOSX11.1.sdk

Monterey:

$ ls -las /Library/Developer/CommandLineTools/SDKs/
total 0
0 drwxr-xr-x  8 root  wheel  256 Apr 20 12:54 .
0 drwxr-xr-x  5 root  wheel  160 Apr 20 12:51 ..
0 lrwxr-xr-x  1 root  wheel   14 Apr 20 12:51 MacOSX.sdk -> MacOSX12.3.sdk
0 drwxr-xr-x  7 root  wheel  224 Apr 20 12:52 MacOSX11.3.sdk
0 lrwxr-xr-x  1 root  wheel   14 Apr 20 12:50 MacOSX11.sdk -> MacOSX11.3.sdk
0 drwxr-xr-x  7 root  wheel  224 Apr 20 12:53 MacOSX12.1.sdk
0 drwxr-xr-x  7 root  wheel  224 Apr 20 12:54 MacOSX12.3.sdk
0 lrwxr-xr-x  1 root  wheel   14 Apr 20 12:49 MacOSX12.sdk -> MacOSX12.3.sdk

If you want to build this against the CLT SDK, it would be correct on Monterey, but not on Catalina?

[kencu (Ken)]

the idea is that all gcc versions on all newer systems are supposed to look here for the SDK:

/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk

Versioned SDKs that were used previously became unreliable when Apple started changing the versioning very frequently, as our gcc versions bake in the SDK path (which is also just plain wrong, the SDK should be found dynamically like xcrun does when using clang, but we can't seem to find a good way to do that with gcc so we bake it in).

[Serge3leo (Serguei E. Leontiev)]

Replying to kencu:

could you undo your workarounds and try this, so we can see what is happening here exactly?

Thanks!

gfortran-mp-9 -v -Wl,-v ref-hello_world.f

$ gfortran-mp-9 -v -Wl,-v ref-hello_world.f
Driving: gfortran-mp-9 -v -Wl,-v ref-hello_world.f -mmacosx-version-min=10.15.0 -asm_macosx_version_min=10.15 -l gfortran -shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran-mp-9
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin19/9.4.0/lto-wrapper
Target: x86_64-apple-darwin19
Configured with: /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc9/gcc9/work/gcc-9.4.0/configure --prefix=/opt/local --build=x86_64-apple-darwin19 --enable-languages=c,c++,objc,obj-c++,lto,fortran,jit --libdir=/opt/local/lib/gcc9 --includedir=/opt/local/include/gcc9 --infodir=/opt/local/share/info --mandir=/opt/local/share/man --datarootdir=/opt/local/share/gcc-9 --with-local-prefix=/opt/local --with-system-zlib --disable-nls --program-suffix=-mp-9 --with-gxx-include-dir=/opt/local/include/gcc9/c++/ --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --with-isl=/opt/local --enable-stage1-checking --disable-multilib --enable-lto --enable-libstdcxx-time --with-build-config=bootstrap-debug --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket --enable-host-shared --disable-tls --with-pkgversion='MacPorts gcc9 9.4.0_1' --with-sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk
Thread model: posix
gcc version 9.4.0 (MacPorts gcc9 9.4.0_1) 
COLLECT_GCC_OPTIONS='-v' '-mmacosx-version-min=10.15.0' '-asm_macosx_version_min=10.15' '-shared-libgcc' '-mtune=core2'
 /opt/local/libexec/gcc/x86_64-apple-darwin19/9.4.0/f951 ref-hello_world.f -ffixed-form -fPIC -quiet -dumpbase ref-hello_world.f -mmacosx-version-min=10.15.0 -mtune=core2 -auxbase ref-hello_world -version -fintrinsic-modules-path /opt/local/lib/gcc9/gcc/x86_64-apple-darwin19/9.4.0/finclude -o /var/folders/wy/z0gbkfgs7mv24ryqkdm90rm40009rh/T//cccr8vn7.s
GNU Fortran (MacPorts gcc9 9.4.0_1) version 9.4.0 (x86_64-apple-darwin19)
	compiled by GNU C version 9.4.0, GMP version 6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran2008 (MacPorts gcc9 9.4.0_1) version 9.4.0 (x86_64-apple-darwin19)
	compiled by GNU C version 9.4.0, GMP version 6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
COLLECT_GCC_OPTIONS='-v' '-mmacosx-version-min=10.15.0'  '-shared-libgcc' '-mtune=core2'
 /opt/local/bin/as -arch x86_64 -v -force_cpusubtype_ALL -mmacosx-version-min=10.15 -o /var/folders/wy/z0gbkfgs7mv24ryqkdm90rm40009rh/T//ccG5NBYg.o /var/folders/wy/z0gbkfgs7mv24ryqkdm90rm40009rh/T//cccr8vn7.s
Apple clang version 12.0.0 (clang-1200.0.32.29)
Target: x86_64-apple-darwin19.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
 "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" -cc1as -triple x86_64-apple-macosx10.15.0 -filetype obj -main-file-name cccr8vn7.s -target-cpu penryn -fdebug-compilation-dir /Users/leo/soft/fortran/ratfor -dwarf-debug-producer "Apple clang version 12.0.0 (clang-1200.0.32.29)" -dwarf-version=4 -mrelocation-model pic -o /var/folders/wy/z0gbkfgs7mv24ryqkdm90rm40009rh/T//ccG5NBYg.o /var/folders/wy/z0gbkfgs7mv24ryqkdm90rm40009rh/T//cccr8vn7.s
Reading specs from /opt/local/lib/gcc9/gcc/x86_64-apple-darwin19/9.4.0/../../../libgfortran.spec
rename spec lib to liborig
COLLECT_GCC_OPTIONS='-v' '-mmacosx-version-min=10.15.0'  '-shared-libgcc' '-mtune=core2'
COMPILER_PATH=/opt/local/libexec/gcc/x86_64-apple-darwin19/9.4.0/:/opt/local/libexec/gcc/x86_64-apple-darwin19/9.4.0/:/opt/local/libexec/gcc/x86_64-apple-darwin19/:/opt/local/lib/gcc9/gcc/x86_64-apple-darwin19/9.4.0/:/opt/local/lib/gcc9/gcc/x86_64-apple-darwin19/
LIBRARY_PATH=/opt/local/lib/gcc9/gcc/x86_64-apple-darwin19/9.4.0/:/opt/local/lib/gcc9/gcc/x86_64-apple-darwin19/9.4.0/../../../
COLLECT_GCC_OPTIONS='-v' '-mmacosx-version-min=10.15.0'  '-shared-libgcc' '-mtune=core2'
 /opt/local/libexec/gcc/x86_64-apple-darwin19/9.4.0/collect2 -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/ -dynamic -arch x86_64 -macosx_version_min 10.15.0 -weak_reference_mismatches non-weak -o a.out -L/opt/local/lib/gcc9/gcc/x86_64-apple-darwin19/9.4.0 -L/opt/local/lib/gcc9/gcc/x86_64-apple-darwin19/9.4.0/../../.. -v /var/folders/wy/z0gbkfgs7mv24ryqkdm90rm40009rh/T//ccG5NBYg.o -lgfortran -lSystem -lgcc_ext.10.5 -lgcc -lquadmath -lm -lgcc_ext.10.5 -lgcc -lSystem -no_compact_unwind -v
collect2 version 9.4.0
/opt/local/bin/ld -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/ -dynamic -arch x86_64 -macosx_version_min 10.15.0 -weak_reference_mismatches non-weak -o a.out -L/opt/local/lib/gcc9/gcc/x86_64-apple-darwin19/9.4.0 -L/opt/local/lib/gcc9/gcc/x86_64-apple-darwin19/9.4.0/../../.. -v /var/folders/wy/z0gbkfgs7mv24ryqkdm90rm40009rh/T//ccG5NBYg.o -lgfortran -lSystem -lgcc_ext.10.5 -lgcc -lquadmath -lm -lgcc_ext.10.5 -lgcc -lSystem -no_compact_unwind -v
@(#)PROGRAM:ld  PROJECT:ld64-609.8
BUILD 15:07:46 Dec 18 2020
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em
@(#)PROGRAM:ld  PROJECT:ld64-609.8
BUILD 15:07:46 Dec 18 2020
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em
Library search paths:
	/opt/local/lib/gcc9/gcc/x86_64-apple-darwin19/9.4.0
	/opt/local/lib/gcc9
	/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/lib
Framework search paths:
	/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/
ld: library not found for -lgcc_ext.10.5
collect2: error: ld returned 1 exit status

...we can see what is happening here exactly?

As I understand it, the old versions port "libgcc" provided files "/opt/local/lib/libgcc/libgcc_s.10.[45].dylib", and port "gcc9" contained symbolic links to them.

But, when switching to gcс11, something has changed.

[Serge3leo (Serguei E. Leontiev)]

Replying to johnrosshunt:

Same problem for me on Catalina with GCC-10. GCC-11 works fine, however.

gcc6, gcc7, gcc8 probably has an identical problem.

[Serge3leo (Serguei E. Leontiev)]

Replying to kencu:

So the gcc10 log shows it is looking here:

/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk

...

IMHO, these are two different problems (libgcc & MacOSX SDK). I replied at ticket 58895

[kencu (Ken)]

Yes, people pile on different problems into unrelated tickets, which is one of the primary problems we ticket-fixers must deal with when trying to sort you folks out, certainly.

in your case /opt/local/lib/gcc9 does not seem to contain a link to libgcc_ext.10.5, whereas in my case, on 10.14 for example, it certainly does:

$ ls -la /opt/local/lib/gcc9/libgcc_ext*
lrwxr-xr-x  1 root  admin  43 25 Dec 12:40 /opt/local/lib/gcc9/libgcc_ext.10.4.dylib -> /opt/local/lib/libgcc/libgcc_ext.10.4.dylib
lrwxr-xr-x  1 root  admin  43 25 Dec 12:40 /opt/local/lib/gcc9/libgcc_ext.10.5.dylib -> /opt/local/lib/libgcc/libgcc_ext.10.5.dylib

so our question for today is -- Why? did you delete it during your deletion festival, or is is somehow not there for you?

how about you reinstall gcc9 and we will find out?

sudo port -f uninstall gcc9 libgcc9
sudo port -v install gcc
ls /opt/local/lib/gcc9/libgcc_ext*

[kencu (Ken)]

just FYI

$ port provides /opt/local/lib/libgcc/libgcc_ext.10.5.dylib
/opt/local/lib/libgcc/libgcc_ext.10.5.dylib is provided by: libgcc11

[Serge3leo (Serguei E. Leontiev)]

Replying to kencu:

just FYI

$ port provides /opt/local/lib/libgcc/libgcc_ext.10.5.dylib
/opt/local/lib/libgcc/libgcc_ext.10.5.dylib is provided by: libgcc11

Probably a previous version libgcc11 @11.2.0_4 or early. Current precompiled version "libgcc11" does not contain libraries libgcc_ext.10.5.dylib and libgcc_ext.10.4.dylib:

$ wget https://packages.macports.org/libgcc11/libgcc11-11.3.0_0.darwin_19.x86_64.tbz2
--2022-04-25 10:54:38--  https://packages.macports.org/libgcc11/libgcc11-11.3.0_0.darwin_19.x86_64.tbz2
Resolving packages.macports.org (packages.macports.org)... 151.101.14.132
Connecting to packages.macports.org (packages.macports.org)|151.101.14.132|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3016188 (2.9M) [application/x-bzip2]
Saving to: 'libgcc11-11.3.0_0.darwin_19.x86_64.tbz2.2'

libgcc11-11.3.0_0.da 100%[====================>]   2.88M  2.19MB/s    in 1.3s    

2022-04-25 10:54:39 (2.19 MB/s) - 'libgcc11-11.3.0_0.darwin_19.x86_64.tbz2.2' saved [3016188/3016188]

$ tar tfj libgcc11-11.3.0_0.darwin_19.x86_64.tbz2 | grep /libgcc/libgcc
./opt/local/lib/libgcc/libgcc_s.1.1.dylib
./opt/local/lib/libgcc/libgcc_s.1.dylib

[Serge3leo (Serguei E. Leontiev)]

Replying to kencu:

how about you reinstall gcc9 and we will find out?

In my original report:

1. Clean macOS & Xcode;
2. Clean MacPorts;
3. sudo port install gcc9

[kencu (Ken)]

So gcc on Catalina, from MacPorts is not broken, in general I believe, unless recently broken.

Hundreds or thousands of ports that require gcc to build are being successfully built by the buildbot all the time, eg

​https://ports.macports.org/port/octave/details/

So we are trying to sort out why your system is apparently broken. It might turn out to be some new MacPorts issue, libgcc11 just was updated, but still not sure yet.

[kencu (Ken)]

If the new libgcc11 no longer supplies those libraries (on some systems?) that would do it.

Could be. We’ll see if that is verified by others too. I seem to have those libraries as above, on Mojave, but I’ll double check my libgcc11 exact version to be certain.

If so, we know the proper solution to that issue, which comes up every now and then.

[kencu (Ken)]

It does indeed appear that the libgcc11 update has removed /opt/local/lib/libgcc/libgcc_ext.10.[4-5].dylib

so that will need to be provided by libgcc10 now presumably.

Chris didn't notice this when updating gcc11 / libgcc11 to 11.3.0, but I'm sure he'll get round to it soon.

[cjones051073 (Chris Jones)]

Replying to kencu:

It does indeed appear that the libgcc11 update has removed /opt/local/lib/libgcc/libgcc_ext.10.[4-5].dylib

so that will need to be provided by libgcc10 now presumably.

Chris didn't notice this when updating gcc11 / libgcc11 to 11.3.0, but I'm sure he'll get round to it soon.

Yeah.... I always check for changes in the dylibs when preparing a new major release, but didn't expect changes like this on a minor revision update...

[Chris Jones <jonesc@…>]

In 8fe231e921aea8c4de3f7b6679cd4abcb0d5716b/macports-ports (master):

libgcc10: Distribute libgcc_ext.10.[4-5].dylib following them being dropped in gcc11
Closes: #65055

[barracuda156]

Replying to Chris Jones <jonesc@…>:

In 8fe231e921aea8c4de3f7b6679cd4abcb0d5716b/macports-ports (master):

libgcc10: Distribute libgcc_ext.10.[4-5].dylib following them being dropped in gcc11
Closes: #65055

Iain says nothing was removed: ​https://github.com/iains/darwin-toolchains-start-here/discussions/32?notification_referrer_id=NT_kwDOBXwLlrMzNTAwNTg5NTk1OjkyMDE1NTEw#discussioncomment-2630831

What should be added however is libgcc_ehs.1.1.dylib.

[cjones051073 (Chris Jones)]

Replying to barracuda156:

Replying to Chris Jones <jonesc@…>:

In 8fe231e921aea8c4de3f7b6679cd4abcb0d5716b/macports-ports (master):

libgcc10: Distribute libgcc_ext.10.[4-5].dylib following them being dropped in gcc11
Closes: #65055

Iain says nothing was removed: ​https://github.com/iains/darwin-toolchains-start-here/discussions/32?notification_referrer_id=NT_kwDOBXwLlrMzNTAwNTg5NTk1OjkyMDE1NTEw#discussioncomment-2630831

What should be added however is libgcc_ehs.1.1.dylib.

Thats not what I see in the gcc11 builds. libgcc_ext.10.[4-5].dylib are no long being produced.

[mascguy (Christopher Nielsen)]

We're hitting this for ports openmpi-gcc7 and openmpi-gcc9, on 10.6 and 10.7. See: issue:65337

So should these libs - or links to them - exist? If not, will this require patching configure [in dependent ports] to fix, or...?

[cjones051073 (Chris Jones)]

gcc9 and older is no longer supported on OSX 10.11 and newer, due to a change w.r.t. @rpath in the latest gcc12, that now provides the default run time, and is (at this time) not supported in gcc9 and older.

Please switch to gcc10 or newer.

[cjones051073 (Chris Jones)]

For more context see ​https://trac.macports.org/ticket/65472

[cjones051073 (Chris Jones)]

So, just to clarify the situation w.r.t. libgcc_ext.10.[4-5].dylib

These dylibs have indeed been removed from gcc(10-12) and are no longer used by these compilers.

For this reason, these files are now provided by libgcc9

Oberon ~/Projects/MacPorts/ports > port contents libgcc9
Port libgcc9 contains:
  /opt/local/lib/libgcc/libasan.5.dylib
  /opt/local/lib/libgcc/libgcc_ext.10.4.dylib
  /opt/local/lib/libgcc/libgcc_ext.10.5.dylib

gcc9 depends on libgcc9, so will be available when you install gcc9.

gcc7 depends on libgcc7, which in turn depends on libgcc8, which in turn requires libgcc9.

So the bottom line is once gcc7 or gcc9 is installed, libgcc9 will also be available at runtime, and thus so should these dylibs.

[cjones051073 (Chris Jones)]

OK, I see the problem...

​https://github.com/macports/macports-ports/blob/6a9d60524bdb301ea9db42887e896ae3a5637e45/lang/gcc9/Portfile#L242

so libgcc9 only ever builds on OSX 10.8 and newer... I must have neglected to remove that check, once it also start providing the libs above..

[Chris Jones <jonesc@…>]

In 61e01e26b3cb2bbbdee8920c44e9e49fc4154f73/macports-ports (master):

libgcc9: Fix build of runtime on OSX10.7 and older
See: #65337
See: #65055

[cjones051073 (Chris Jones)]

Note the above fixes the issue on 10.7 and older. However, its still the case that using gcc9 and older on 10.11 and newer is still no longer supported due to the rpath migration.

[rmottola (Riccardo)]

Hi! I reopen this... because it is apparently not fixed. Just as yesterday, I hit this error on mac 10.13

ld: library not found for -lgcc_s.10.5

Both when using clang and gcc12 when building something (not in macports).

I reopen this bug because this is happens on a clean system, installed from scratch 10.13 and macports directly, so there is no legacy, no older ports, deleted symlinks, etc etc. Direct install of clang15 and gcc12.

Why using those compilers I need an older library?

My "guess" is that on 10.13 most (but not all) packages were installed as binary, so perhaps somehow one binary was not rebuilt on the buildbots? Or on the buildbots the said library is present? Just wildly guessing!

[kencu (Ken)]

I think we are going to need some very specific instructions how to reproduce this to make headway. Pls go through exactly what you do to make this error happen, starting from no installed ports if you can.

[rmottola (Riccardo)]

This error happens during configure of ArcticFox, so not exactly a "light" process, however it is something we know works using macports compilers on 10.6 and 10.7. I installed most dependencies and have 3 compilers, here an excerpt of relevant ones:

  cctools @949.0.1_2+llvm10 (active)
  clang-6.0 @6.0.1_4+analyzer+emulated_tls+libstdcxx (active)
  clang-15 @15.0.7_1+analyzer+libstdcxx (active)
  gcc12 @12.2.0_2+stdlib_flag (active)
  gcc12-libcxx @12.2.0_4+clang14 (active)
  libgcc @6.0_0 (active)
  libgcc12 @12.2.0_2+stdlib_flag (active)
  ld64 @3_4 (active)
  ld64-latest @450.3_0+llvm90 (active)
  llvm-6.0 @6.0.1_4 (active)
  llvm-9.0 @9.0.1_3+emulated_tls (active)
  llvm-10 @10.0.1_3+emulated_tls (active)
  llvm-15 @15.0.7_0 (active)

is the double libgcc normal? llvm-9.0 is there because of ld64

This is my failure:

 0:20.74 js/src> configure:8144: checking for -dead_strip option to ld
 0:20.74 js/src> configure:8155: /opt/local/bin/ccache clang-mp-15 -march=corei7 -mtune=corei7 -o conftest  -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk -std=gnu99 -fno-common -Qunused-arguments   -lobjc -Wl,-dead_strip conftest.c  1>&5
 0:20.74 js/src> ld: library not found for -lgcc_s.10.5
 0:20.74 js/src> clang: error: linker command failed with exit code 1 (use -v to see invocation)

I tried compiling a simple hello world in C with gcc12, clang6 clang15 and it works.

I tried using the full command line of the test:

clang-mp-15 -march=corei7 -mtune=corei7 -o conftest  -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk -std=gnu99 -fno-common -Qunused-arguments   -lobjc -Wl,-dead_strip hello.c 

and it works. The test however, runs through ccache

/opt/local/bin/ccache clang-mp-15 -march=corei7 -mtune=corei7 -o conftest  -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk -std=gnu99 -fno-common -Qunused-arguments   -lobjc -Wl,-dead_strip hello.c

and it still works! And the absurd thing is that if I type out the test program, go into the subdirectory and issue exactly

/opt/local/bin/ccache clang-mp-15 -march=corei7 -mtune=corei7 -o conftest  -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk -std=gnu99 -fno-common -Qunused-arguments   -lobjc -Wl,-dead_strip conftest.c

it works.... I'm puzzled. I removed optimization flags, fails the same.

 0:37.91 js/src> configure:8142: checking for -dead_strip option to ld
 0:37.91 js/src> configure:8153: /opt/local/bin/ccache clang-mp-15  -o conftest  -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk -std=gnu99 -fno-common -Qunused-arguments   -lobjc -Wl,-dead_strip conftest.c  1>&5
 0:37.91 js/src> ld: library not found for -lgcc_s.10.5

[kencu (Ken)]

so

 0:20.74 js/src> configure:8144: checking for -dead_strip option to ld
 0:20.74 js/src> configure:8155: /opt/local/bin/ccache clang-mp-15 -march=corei7 -mtune=corei7 -o conftest  -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk -std=gnu99 -fno-common -Qunused-arguments   -lobjc -Wl,-dead_strip conftest.c  1>&5
 0:20.74 js/src> ld: library not found for -lgcc_s.10.5
 0:20.74 js/src> clang: error: linker command failed with exit code 1 (use -v to see invocation)

clang-mp-15 should not be looking for any version of libgcc, at all when trying to drive this link, unless something weird is going on.

You are on what exact system? What is the deployment target set to (env var or other)?

I note you are not setting the -stdlib=libXYZ option, so I am not sure what stdlib you are trying to / hoping to build aginst. The call for libgcc_s.10.5 suggests libstdc++ is being called in (some version of it, either system or macports version). That is probably wrong, although might be what you are after?

You do need to nail these things right down when you're going off-defaults. Spec them all.

Add a -Wl,-v to the build line to see what the linker is thinking it is trying to do here.