___addtf3 link error against libgcc_s.1.1.dylib

[crazypill]

The WSJT-X code links against libgfortran (which on disk is libgfortran.5.dylib). libgfortran depends on libgcc_s.1.1.dylib but that version of the library doesn't contain the new nested function code ___addtf3 but libgcc_s.dylib does contain the symbol as expected.

I'm currently just manually replacing libgcc_s.1.1.dylib with libgcc_s.dylib (and renaming it back to libgcc_s.1.1.dylib) in the app bundle and that works fine. But I wanted to ask if this is expected behavior? I can't think of a reason not to include ___addtf3 to libgcc_s.1.1. I tried updating the CMake reference from gcc_s.1 to gcc but that had no effect as it's libgfortran that has the dependency and not WSJT-X directly.

Thanks again for your help!

[iains]

what does libgcc_s.dylib point to? @fxcoudert - is this some aspect of the HB packaging as we were discussing by email?

libgfortran depends on libgcc_s.1.1.dylib but that version of the library doesn't contain the new nested function code

So something in your build is out of sync - the new compiler should make a new libgcc_s.1.1.dylib (there will be no libgcc_s.1.dylib for Arm64, that version of the library will only be built for legacy support).

my latest build contains this:

-rw-r--r--  1 iains  staff    681024 29 Dec 14:01 gcc/libgcc.a
-rw-r--r--  1 iains  staff    138363 29 Dec 14:01 gcc/libgcc_s.1.1.dylib

and it has the symbol that you want (TF handling is also a recent addition to the aarch64-darwin port :) )

$ nm -mapv gcc/libgcc_s.1.1.dylib |grep addtf3
0000000000008210 (__TEXT,__text) external ___addtf3

[crazypill]

I built gcc/gfortran from your source repo.
@.***:iains/gcc-darwin-arm64.git

It built both libs as far as I can tell, they both have the same date as the rest of the build.

-rw-r--r-- 1 alex staff 32041 Dec 27 12:35 libgcc-std.ver -rw-r--r-- 1 alex staff 669440 Dec 27 12:35 libgcc.a -rw-r--r-- 1 alex staff 1397 Dec 27 12:35 libgcc.map -rw-r--r-- 1 alex staff 31730 Dec 27 12:35 libgcc.map.in -rw-r--r-- 1 alex staff 188888 Dec 27 12:35 libgcc_eh.a -rwxr-xr-x 1 alex staff 138587 Dec 27 12:35 libgcc_s.1.1.dylib -rwxr-xr-x 1 alex staff 122203 Dec 27 12:35 libgcc_s.dylib -rw-r--r-- 1 alex staff 169 Dec 27 12:35 libgcc_tm.h -rw-r--r-- 1 alex staff 10 Dec 27 12:35 libgcc_tm.stamp

On Dec 29, 2021, at 3:55 PM, iains @.***> wrote:

what does libgcc_s.dylib point to? @fxcoudert https://github.com/fxcoudert - is this some aspect of the HB packaging as we were discussing by email?

libgfortran depends on libgcc_s.1.1.dylib but that version of the library doesn't contain the new nested function code

So something in your build is out of sync - the new compiler should make a new libgcc_s.1.1.dylib (there will be no libgcc_s.1.dylib for Arm64, that version of the library will only be built for legacy support).

my latest build contains this:

-rw-r--r-- 1 iains staff 681024 29 Dec 14:01 gcc/libgcc.a -rw-r--r-- 1 iains staff 138363 29 Dec 14:01 gcc/libgcc_s.1.1.dylib and it has the symbol that you want (TF handling is also a recent addition to the aarch64-darwin port :) )

$ nm -mapv gcc/libgcc_s.1.1.dylib |grep addtf3 0000000000008210 (TEXT,text) external ___addtf3 — Reply to this email directly, view it on GitHub https://github.com/iains/gcc-darwin-arm64/issues/79#issuecomment-1002817260, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGXUSKY77AWTGFWMPSSSDLUTONYNANCNFSM5K6Y4FLQ. You are receiving this because you authored the thread.

[iains]

-rwxr-xr-x  1 alex  staff  138587 Dec 27 12:35 libgcc_s.1.1.dylib
-rwxr-xr-x  1 alex  staff  122203 Dec 27 12:35 libgcc_s.dylib

I do not understand where the second lib is coming from - it's plainly not a symlink, so what built it?

please could you do;

otool -Lv on both libraries and nm -mapv .... | grep addtf3 on both

[crazypill]

boop>:/Users/alex/gcc-darwin-arm64/build/aarch64-apple-darwin21/libgcc% otool -Lv  libgcc_s.1.1.dylib 
libgcc_s.1.1.dylib (architecture arm64):
    /usr/local/lib/libgcc_s.1.1.dylib (compatibility version 1.0.0, current version 1.1.0)
    time stamp 1 Wed Dec 31 16:00:01 1969
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.0.0)
    time stamp 2 Wed Dec 31 16:00:02 1969
boop>:/Users/alex/gcc-darwin-arm64/build/aarch64-apple-darwin21/libgcc% otool -Lv  libgcc_s.dylib    
libgcc_s.dylib:
    /usr/local/lib/libgcc_s.1.1.dylib (compatibility version 1.0.0, current version 1.1.0)
    time stamp 1 Wed Dec 31 16:00:01 1969
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.0.0)
    time stamp 2 Wed Dec 31 16:00:02 1969

boop>:/Users/alex/gcc-darwin-arm64/build/aarch64-apple-darwin21/libgcc% nm -mapv libgcc_s.1.1.dylib | grep addtf3
0000000000000000 (?) non-external addtf3.c
0000000061ca239c (?) non-external /Users/alex/gcc-darwin-arm64/build/aarch64-apple-darwin21/libgcc/addtf3_s.o
0000000000008210 (?) non-external ___addtf3
0000000000008210 (__TEXT,__text) external ___addtf3

boop>:/Users/alex/gcc-darwin-arm64/build/aarch64-apple-darwin21/libgcc% nm -mapv libgcc_s.dylib | grep addtf3
0000000000000000 (?) non-external addtf3.c
0000000061ca239c (?) non-external /Users/alex/gcc-darwin-arm64/build/aarch64-apple-darwin21/libgcc/addtf3_s.o
0000000000008210 (?) non-external ___addtf3
0000000000008210 (__TEXT,__text) external ___addtf3

Ok so from this it seems that both libraries have the symbol! It seems that the WSJT-X 'make install' phase is getting libgcc_s.1.1.dylib from somewhere else! It looks like it is in /usr/local/lib/libgcc_s.1.1.dylib.

Anyway so you are definitely correct that my build is out of sync somehow. I thought that 'sudo make install' on gcc would replace the libs in /usr/local/lib... Maybe I misconfigured the gcc build.

[fxcoudert]

Sadly, the macOS system developer tools have a bad habit of looking up things in /usr/local/{include,lib} automagically. I think @iains and I both recommend not to install your toolchain at this path (specify a --prefix that is not /usr/local; it can be somewhere down that hierarchy, like /usr/local/gcc-12-20211230 or whatever).

[iains]

agreed : for my 0.02GBP

• if you expect your user to have admin privs, then somewhere in /opt/<vendor>/ (where 'vendor' is appropriate to your distribution - e.g. my setting is usually "iains"). That way you should be sure that you will not clash with Apple, any other distribution or any other packager.
• If you do not expect your user to have admin privs, then consider installing in /Users/Shared/<vendor>/or arranging your package so that the user can install in their home dir.

[crazypill]

So WSJT-X builds on pretty much all the OSes using CMake which spits out unix make files. The issue I'm running into is that the WSJT-X build script for Mac copies a slew of libraries into the App's Bundle into the Framework directory. This is why I was assuming (and hoping) that the newer gcc I built would install into the default path because that's where WSJT-X 'make install' expects to find them (in /usr/local/lib).

I will have to look to see if I can override where the WSJT-X install script picks up its libraries so that I can install gcc somewhere less generic to avoid this out-of-sync issue and then point the WSJT-X install phase at those binaries for packaging.

My guess is that the out of date libgcc I have in my /usr/local/lib was installed by HomeBrew which is where I first started off on this journey. I then upgraded to the latest gcc from your branch (specifically for ___addtf3) and didn't pay attention to the install prefix. This is most likely how I caused this problem. Actually looking at my configure string for gcc, I don't seem to even specify the install prefix, didn't even cross my mind. oops.

../configure --build=aarch64-apple-darwin21 --disable-nls --enable-checking=release --enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-10 --with-gmp=/opt/homebrew/opt/gmp --with-mpfr=/opt/homebrew/opt/mpfr --with-mpc=/opt/homebrew/opt/libmpc --with-isl=/opt/homebrew/opt/isl --with-system-zlib --disable-multilib --with-native-system-header-dir=/usr/include --disable-darwin-at-rpath --with-sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk

Thanks for all of your help- sounds like it's time for me to clean out my copies of gcc and rebuild and install somewhere known to me! Hope you all have a great New Year. Best wishes...