Opened 3 years ago
Last modified 21 months ago
#65055 reopened defect
libgcc11 11.3.0 update has removed libgcc_ext.10.[4-5].dylib
Reported by: | Serge3leo (Serguei E. Leontiev) | Owned by: | Chris Jones <jonesc@…> |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.7.2 |
Keywords: | Cc: | cooljeanius (Eric Gallager), cjones051073 (Chris Jones) | |
Port: | libgcc11, gcc6, gcc7, gcc8, gcc9, gcc10 |
Description (last modified by 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
Attachments (2)
Change History (41)
comment:1 Changed 3 years ago by Serge3leo (Serguei E. Leontiev)
comment:2 Changed 3 years ago by Serge3leo (Serguei E. Leontiev)
Description: | modified (diff) |
---|---|
Version: | → 2.7.2 |
comment:3 Changed 3 years ago by Serge3leo (Serguei E. Leontiev)
Summary: | libgcc9 broken symbolic link libgcc_ext.10.5.dylib and libgcc_ext.10.4.dylib → Broken symbolic link libgcc_ext.10.5.dylib and libgcc_ext.10.4.dylib |
---|
comment:4 follow-up: 11 Changed 3 years ago by 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
comment:5 follow-up: 12 Changed 3 years ago by johnrosshunt
Same problem for me on Catalina with GCC-10. GCC-11 works fine, however.
Changed 3 years ago by johnrosshunt
Attachment: | gcc10.log.gz added |
---|
Changed 3 years ago by johnrosshunt
Attachment: | gcc11.log.gz added |
---|
comment:6 follow-up: 14 Changed 3 years ago by 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
So they should be built to look here:
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
I wonder what is wrong with this plan?
comment:7 Changed 3 years ago by kencu (Ken)
Port: | gcc10 added |
---|---|
Summary: | Broken symbolic link libgcc_ext.10.5.dylib and libgcc_ext.10.4.dylib → gcc10 (and probably gcc9) are looking in the wrong location for the SDK again |
comment:8 Changed 3 years ago by kencu (Ken)
Summary: | gcc10 (and probably gcc9) are looking in the wrong location for the SDK again → Broken symbolic link libgcc_ext.10.5.dylib and libgcc_ext.10.4.dylib |
---|
actually I will revert that until we hear back from the gcc9 reporter
comment:9 Changed 3 years ago by 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?
comment:10 Changed 3 years ago by 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).
comment:11 Changed 3 years ago by 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.
comment:12 Changed 3 years ago by 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.
comment:13 Changed 3 years ago by Serge3leo (Serguei E. Leontiev)
Port: | libgcc gcc6 gcc7 gcc8 added |
---|
comment:14 Changed 3 years ago by 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
comment:15 follow-up: 18 Changed 3 years ago by 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*
comment:16 follow-up: 17 Changed 3 years ago by 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
comment:17 Changed 3 years ago by 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
comment:18 Changed 3 years ago by Serge3leo (Serguei E. Leontiev)
Replying to kencu:
how about you reinstall gcc9 and we will find out?
In my original report:
- Clean macOS & Xcode;
- Clean MacPorts;
- sudo port install gcc9
comment:19 Changed 3 years ago by Serge3leo (Serguei E. Leontiev)
Port: | libgcc11 added; libgcc removed |
---|
comment:20 Changed 3 years ago by 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.
comment:21 Changed 3 years ago by 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.
comment:22 Changed 3 years ago by cooljeanius (Eric Gallager)
Cc: | cooljeanius added |
---|
comment:23 follow-up: 25 Changed 3 years ago by 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.
comment:24 Changed 3 years ago by kencu (Ken)
Cc: | cjones051073 added |
---|---|
Summary: | Broken symbolic link libgcc_ext.10.5.dylib and libgcc_ext.10.4.dylib → libgcc11 11.3.0 update has removed libgcc_ext.10.[4-5].dylib |
comment:25 Changed 3 years ago by 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...
comment:26 follow-up: 27 Changed 3 years ago by Chris Jones <jonesc@…>
Owner: | set to Chris Jones <jonesc@…> |
---|---|
Resolution: | → fixed |
Status: | new → closed |
comment:27 follow-up: 28 Changed 3 years ago by barracuda156
Replying to Chris Jones <jonesc@…>:
In 8fe231e921aea8c4de3f7b6679cd4abcb0d5716b/macports-ports (master):
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
.
comment:28 Changed 3 years ago by cjones051073 (Chris Jones)
Replying to barracuda156:
Replying to Chris Jones <jonesc@…>:
In 8fe231e921aea8c4de3f7b6679cd4abcb0d5716b/macports-ports (master):
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.
comment:29 Changed 2 years ago by 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...?
comment:30 Changed 2 years ago by 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.
comment:31 Changed 2 years ago by cjones051073 (Chris Jones)
For more context see https://trac.macports.org/ticket/65472
comment:32 Changed 2 years ago by 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.
comment:33 Changed 2 years ago by cjones051073 (Chris Jones)
OK, I see the problem...
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..
comment:34 Changed 2 years ago by Chris Jones <jonesc@…>
comment:35 Changed 2 years ago by 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.
comment:36 Changed 21 months ago by rmottola (Riccardo)
Resolution: | fixed |
---|---|
Status: | closed → reopened |
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!
comment:37 Changed 21 months ago by 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.
comment:38 Changed 21 months ago by 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
comment:39 Changed 21 months ago by 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.
Workaround: