Link time error with Apple Clang 17 and gfortran 14: ld: -lto_library library filename must be 'libLTO.dylib'

This morning, my Mac updated to the latest XCode Commandline Tools, aka Apple Clang 17:

❯ clang --version
Apple clang version 17.0.0 (clang-1700.0.13.3)
Target: arm64-apple-darwin24.4.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

I then nuked my Spack installs and rebuild my stack and when I did so the compilation died in OpenBLAS:

ld: -lto_library library filename must be 'libLTO.dylib'
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:320: sblat1] Error 1
make[1]: *** Waiting for unfinished jobs....
ld: -lto_library library filename must be 'libLTO.dylib'
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:331: dblat1] Error 1

But, Spack can be odd sometimes, so I grabbed OpenBLAS 0.3.29 and built it as:

make MAKE_NB_JOBS=0 ARCH=arm64 DYNAMIC_ARCH=1 DYNAMIC_OLDER=1 \
  TARGET=GENERIC DYNAMIC_ARCH=1 USE_LOCKING=1 USE_OPENMP=0 \
  USE_THREAD=0 RANLIB=ranlib NO_AVX512=1 all |& tee make.log

which is what Spack was building as. In this build, CC=clang CXX=clang++ FC=gfortran-14 where gfortran-14 is from Brew.

Eventually my build failed with:

touch libopenblas-r0.3.29.a
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C test all
/Users/mathomp4/.homebrew/brew/bin/gfortran-14 -O2 -Wall -frecursive -fno-optimize-sibling-calls -fPIC -fno-tree-vectorize -c sblat1.f  -o sblat1.o
/Users/mathomp4/.homebrew/brew/bin/gfortran-14 -O2 -Wall -frecursive -fno-optimize-sibling-calls  -fno-tree-vectorize  -o sblat1 sblat1.o ../libopenblas-r0.3.29.a -lgfortran -lgfortran -L/usr/local/lib  -lto_library -lSystem  /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/17/lib/darwin/libclang_rt.osx.a
ld: -lto_library library filename must be 'libLTO.dylib'
collect2: error: ld returned 1 exit status
make[1]: *** [sblat1] Error 1
make: *** [tests] Error 2

Now, I'm currently doing a reinstall of gfortran-14 from source (as on this machine, I don't have admin access, so I have to install Brew in userspace), but is anyone else seeing this? Or have a solution?

Are you setting any additional flags in the environment ? There is nothing in the stock OpenBLAS build files that would add the -lto_library option that it seems to be complaining about

@martin-frbg

Are you setting any additional flags in the environment ? There is nothing in the stock OpenBLAS build files that would add the -lto_library option that it seems to be complaining about

@martin-frbg Not really. I do have a modulefile to load my clang-gfortran/14 env, but that only has:

setenv("CC",pathJoin(cbindir,"clang"))
setenv("CXX",pathJoin(cbindir,"clang++"))
setenv("FC",pathJoin(fbindir,"gfortran-14"))
setenv("F90",pathJoin(fbindir,"gfortran-14"))

-- per @scivision, set OpenMP_ROOT for clang: https://gist.github.com/scivision/16c2ca1dc250f54d34f1a1a35596f4a0
setenv("OpenMP_ROOT",pathJoin(homebrewdir,"opt/libomp"))

And as the build above has USE_OPENMP=0 I'm assuming the latter doesn't matter. So all I'm doing is setting the usual CC etc.

My current thought is maybe the from-source brew build of gfortran-14 might be hosed, but at the moment I can't reinstall (see GMAO-SI-Team/geosesm-spack#2) so...yeah.

The -lto_library option is most likely copied from what Apple Clang itself does when compiling the test file during the initial c_check script run (see the CEXTRALIB in the generated Makefile.conf). Unfortunately I cannot find any reference to recent changes in the option syntax (like requiring libLTO.dylib to be expressly named with that option) nor any search hits for the error message you quoted.
Trying to update XCode on my own M4 does not produce anything newer than 16.3 with Clang-16 right now.
Perhaps check if your upgrade left you without libLTO.dylib (e.g. with only its static version), or with a version that is somehow incompatible with your hardware ?

@martin-frbg

@martin-frbg I'll take a look on Monday when I'm back at work. So weird...

That said, I think I was able to build OpenBLAS with pure gcc/gfortran and Spack (that is, avoiding Clang).

Hit this as well while setting up a new M4.

@pbrady

@martin-frbg I'll take a look on Monday when I'm back at work. So weird...

That said, I think I was able to build OpenBLAS with pure gcc/gfortran and Spack (that is, avoiding Clang).

Note: Like @pbrady I was NOT able to build with pure gcc/gfortran:

==> Error: ProcessError: Command exited with status 2:
    '/Users/mathomp4/spack-mathomp4/opt/spack/darwin-m2/gmake-4.4.1-kz6bdpylf4e3yt4go4kiznkiouaf4wcb/bin/make' '-j6' '-s' 'CC=/Users/mathomp4/spack-mathomp4/opt/spack/darwin-m2/compiler-wrapper-1.0-cdasmd2yy77m4m6wp6mdpf72p6usoqcq/libexec/spack/gcc/gcc' 'FC=/Users/mathomp4/spack-mathomp4/opt/spack/darwin-m2/compiler-wrapper-1.0-cdasmd2yy77m4m6wp6mdpf72p6usoqcq/libexec/spack/gcc/gfortran' 'MAKE_NB_JOBS=0' 'ARCH=arm64' 'DYNAMIC_ARCH=1' 'DYNAMIC_OLDER=1' 'TARGET=GENERIC' 'DYNAMIC_ARCH=1' 'USE_LOCKING=1' 'USE_OPENMP=0' 'USE_THREAD=0' 'RANLIB=ranlib' 'NO_AVX512=1' 'all'

3 errors found in build log:
     6005       27 |     int i, j, info;
     6006          |               ^~~~
     6007    ld: warning: duplicate -rpath '/Users/mathomp4/.homebrew/brew/Cellar/gcc/14.2.0_1/lib/gcc/current/gcc/aarch64-apple-darwin23/14' ignored
     6008    ld: warning: duplicate -rpath '/Users/mathomp4/.homebrew/brew/Cellar/gcc/14.2.0_1/lib/gcc/current' ignored
     6009    ld: warning: ignoring duplicate libraries: '-lSystem', '-lemutls_w', '-lgfortran', '-lheapt_w'
     6010    ld: invalid r_symbolnum=25 in 'test_potrs.o'
  >> 6011    collect2: error: ld returned 1 exit status
  >> 6012    make[1]: *** [Makefile:78: openblas_utest] Error 1
  >> 6013    make: *** [Makefile:172: tests] Error 2

See build log for details:
  /var/folders/4t/b2c40c4149dfm599b9pc_7mr0000gp/T/mathomp4/spack-stage/spack-stage-openblas-0.3.29-xsdxb3g3jgvh2fpe2srz2o6m65m2uawb/spack-build-out.txt

ETA: It seems to die in the testing phase:

 Test of subprogram number  9            ZDSCAL
                                    ----- PASS -----

 Test of subprogram number 10            IZAMAX
                                    ----- PASS -----
test_kernel_regress.c: In function '__ctest_kernel_regress_skx_avx_run':
test_kernel_regress.c:27:15: warning: variable 'info' set but not used [-Wunused-but-set-variable]
   27 |     int i, j, info;
      |               ^~~~
ld: warning: duplicate -rpath '/Users/mathomp4/.homebrew/brew/Cellar/gcc/14.2.0_1/lib/gcc/current/gcc/aarch64-apple-darwin23/14' ignored
ld: warning: duplicate -rpath '/Users/mathomp4/.homebrew/brew/Cellar/gcc/14.2.0_1/lib/gcc/current' ignored
ld: warning: ignoring duplicate libraries: '-lSystem', '-lemutls_w', '-lgfortran', '-lheapt_w'
ld: invalid r_symbolnum=25 in 'test_potrs.o'

I have a thought. I'm testing now to see. Long shot, but possible...

@martin-frbg

Okay. Good news, I can build with pure gcc/gfortran. Bad news, the fix doesn't help with apple-clang/gfortran.

Now, I can make a PR here, but I want to make sure I do it correctly for @martin-frbg 's sake. My current "fix" is a simple copy-paste:

develop...mathomp4:OpenBLAS:bugfix/fix-for-xcode-16

Essentially I duplicate:

ifeq (x$(XCVER), x 15)
CCOMMON_OPT += -Wl,-ld_classic
FCOMMON_OPT += -Wl,-ld_classic
endif

and make the 15, a 16. And it does seem to work when installed as:

spack install 'openblas@develop %[virtuals=c,cxx,fortran] gcc@14.2.0'

and:

spack install 'openblas@0.3.29 %[virtuals=c,cxx,fortran] gcc@14.2.0'

when doing the change in spack land, see spack/spack@develop...mathomp4:spack:bugfix/fix-for-xcode-16-openblas

The reason I'd like @martin-frbg 's advice is that my fix is currently a bit ... heavy-handed? Maybe? I mean, 0.3.29 has apparently been building fine with XCode 16 until now. It was only XCode 16.3 that really triggered this. So:

ifeq (x$(XCVER), x 16)

seems overkill. But I suppose if it doesn't hurt older versions... 🤷🏼

Strange but I guess it is possible that they reintroduced an xcode 15 bug in 16.3 . AFAIR the ld_classic was supposed to go away at some point though...

suspect the fix for the "library file name must be libLTO.dylib" is simply to $filter-out the -lto_library from CEXTRALIB when xcode==16 and FC=gfortran

will create a PR later today

> /usr/bin/clang -ld_classic
ld: warning: -ld_classic is deprecated and will be removed in a future release

Would be great to have support for the new linker before ld_classic disappears.

@martin-frbg

@martin-frbg I made a PR to spack in spack/spack#49976 that uses the changes in #5207 but applied to 0.3.29 (as at this point, openblas@develop would work.

Navigation Menu

Repository navigation

Link time error with Apple Clang 17 and gfortran 14: ld: -lto_library library filename must be 'libLTO.dylib' #5202

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Link time error with Apple Clang 17 and gfortran 14: ld: -lto_library library filename must be 'libLTO.dylib' #5202

Description

Activity

martin-frbg commented on Apr 1, 2025

mathomp4 commented on Apr 1, 2025

martin-frbg commented on Apr 2, 2025

mathomp4 commented on Apr 3, 2025

pbrady commented on Apr 4, 2025

mathomp4 commented on Apr 4, 2025

mathomp4 commented on Apr 4, 2025

mathomp4 commented on Apr 4, 2025

martin-frbg commented on Apr 5, 2025

martin-frbg commented on Apr 5, 2025

martin-frbg commented on Apr 6, 2025

adamjstewart commented on Apr 7, 2025

mathomp4 commented on Apr 8, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions