dynamically links without warning, despite `static` in config

[lefp]

Describe the bug

I have dependency('SDL3', static: true), but the output is still dynamically linked to SDL3.

To reproduce

meson.build:

project('test', 'c')

deps = []
deps += dependency('SDL3', static: true)

executable('out', 'main.c', dependencies: deps)

main.c:

#include <SDL3//SDL.h>

int main(void)
{
    SDL_Init(0);
}

Commands:

meson setup build && meson compile -C build
ldd build/out

Result:

	linux-vdso.so.1 (0x00007f578a71d000)
	libSDL3.so.0 => /lib64/libSDL3.so.0 (0x00007f578a400000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f578a20d000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f578a127000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f578a71f000)

Expected behavior

Meson either statically links SDL3 or throws an error.

The following CMakeLists.txt, for example, links correctly:

cmake_minimum_required(VERSION 3.30)
project(project_name)

find_package(SDL3 REQUIRED CONFIG REQUIRED COMPONENTS SDL3-static)
add_executable(out main.c)
target_link_libraries(out PRIVATE SDL3::SDL3-static)

Command:

mkdir build && cd build && cmake .. && make && ldd out

Result:

	linux-vdso.so.1 (0x00007ff355f26000)
	libm.so.6 => /lib64/libm.so.6 (0x00007ff355e18000)
	libc.so.6 => /lib64/libc.so.6 (0x00007ff355c25000)
	/lib64/ld-linux-x86-64.so.2 (0x00007ff355f28000)

system parameters

OS: Fedora
Python: 3.13.2
Meson: 1.5.1
Ninja: 1.12.1

[lefp]

I just found that lowercasing SDL3 (dependency('sdl3', static: true)) causes it to link correctly.

What could be the cause of the difference between sdl3 and SDL3?

[eli-schwartz]

CMake requires you to know the name of the cmake variable containing the dependency you want, and may export different cmake variables containing differently built dependencies. Using pkg-config we can check for both and use whatever is available, or warn if we see the wrong type. Using the cmake dependency finder we are reliant on quite a bit of guesswork and e.g. specifying the modules: to use manually. If we somehow select the wrong cmake variable then it will have library properties that contain absolute pathnames to the shared library and may not end up warning you.

...

I think the difference in casing is because lowercase is the pkg-config name but uppercase is the *Config.cmake name?

[lefp]

That makes sense, thanks for the explanation. And yes, the pkg-config and CMake config do have that casing difference.

I now see that this is documented here.

When using the CMake dependency and manually specifying the components and modules, why doesn't this work?

project('test', 'c')

deps = []
deps += dependency('SDL3', method: 'cmake', components: ['SDL3-static'], modules: ['SDL3::SDL3-static'])

executable('out', 'main.c', dependencies: deps)

This causes a bunch of linker errors due to cstdlib math functions not being found (fmod, fmodf, etc).
Here's part of the log:

[2/2] Linking target out
FAILED: out
cc  -o out out.p/main.c.o -Wl,--as-needed -Wl,--no-undefined -pthread /usr/lib64/libSDL3.a

Notice the lack of -lm, which I assume is needed there.