Static library fails to link with specific compiler-linker combinations

Bug description I just switched from CMake to Meson, and I noticed that when compiling Pistache as a static library with Clang and the default Debian linker (ld.bfd) and with GCC + LLD I get an error when linking it to the main program. The issue does not appear when using GCC + ld, Clang + LLD, or CMake.

Here’s the Clang + ld error: /usr/bin/ld: subprojects/pistache/libcm_pistache_static.a: error adding symbols: archive has no index; run ranlib to add one

[33/33] Linking target Scraf
FAILED: Scraf 
c++  -o Scraf Scraf.p/meson-generated_student_odb.cpp.o Scraf.p/meson-generated_school_class_odb.cpp.o Scraf.p/meson-generated_school_odb.cpp.o Scraf.p/meson-generated_teacher_odb.cpp.o Scraf.p/src_main.cpp.o -flto -Wl,--as-needed -Wl,--no-undefined -Wl,--start-group subprojects/pistache/libcm_pistache_static.a -pthread /usr/lib/x86_64-linux-gnu/libssl.so /usr/lib/x86_64-linux-gnu/libcrypto.so /usr/local/lib/libodb.so /usr/local/lib/libodb-pgsql.so /usr/lib/x86_64-linux-gnu/libgtest.a -lpthread /usr/lib/x86_64-linux-gnu/libsimdjson.so.5.0.0 /usr/lib/x86_64-linux-gnu/libsodium.so -Wl,--end-group -Wl,-rpath,/usr/local/lib -Wl,-rpath-link,/usr/local/lib
/usr/bin/ld: subprojects/pistache/libcm_pistache_static.a: error adding symbols: archive has no index; run ranlib to add one
clang: error: linker command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.

Steps to reproduce

1. Clone scraf-backend
2. Build the project using Clang + ld.bfd or GCC + LLD

meson.build I’m using (lines 1-33 should’t be relevant)

System parameters

• Build type: Native build, both debug and release
• Operating system: Debian Testing
• Python: 3.9.1
• Meson: 0.56.2
• Ninja: 1.10.1

[Tachi107]

Okay, I have this vague memory that you need to use either lld or gold to do LTO, but that might be wrong.

I think that this also happened when using Clang + gold (and already happens with GCC + LLD)

There’s also this: #8831

Ie, you can’t mix GCC and LLVM based LTO targets (unless the LTO is finished arleady, like "link a gcc executable with a clang shared library))

Uhm, you’re probably right, but I’d like to investigate this a bit more. I’ll do it tomorrow 😃

[Tachi107]

I haven’t been able to reproduce this in a minimal project, but today I’ve encountered this CMake issue: https://gitlab.kitware.com/cmake/cmake/-/issues/20818

Maybe this is caused by Meson not defining CMAKE_INTERPROCEDURAL_OPTIMIZATION when b_lto is enabled?