Subproject links against dynamic library when building both despite -Ddefault_library=static

[CoffeeFlux]

Minimal example: https://github.com/Myaamori/meson_mwe/tree/master/default_options_override

This is a simple project that calls a subproject in which default_options: ['default_library=both'] is specified.

Build with:

meson -Ddefault_library=static build
ninja -v -C build default_options_override

Meson will link against the shared version of the library when it should opt for the static.

Python version: 3.8.2
Meson version: 0.56.0

[CoffeeFlux]

Any chance of getting this looked at or labeled? I can work around the bug, but it's annoying having to manually specify the default_library for the subproject and that repro is extremely simple.

[tristan957]

@CoffeeFlux this is the expected behavior. When you set default_library in line #1 of your example, you are telling Meson that I want my libraries built statically. In order to make subprojects build statically you need -D$subproject:default_library=static or

a_dep = subproject('a', default_options: ['default_library=static']).get_variable('a_dep')

[tristan957]

default_library is a per subproject setting and doesn't inherit from the parent project.

[CoffeeFlux]

I realize that default_library is set per-subproject, but both is a unique case where you have both a static and shared version built and Meson has to decide which one to link against.

I guess the problem is that default_library specifies how to build but not how to link, and Meson just always links against the shared version by default? I understand the desire not to conflate the two needs, but it's a bit frustrating that I don't have a way to encourage static linking on certain platforms without just hard-coding it everywhere in the build scripts.

[eli-schwartz]

What's the general use case of building a shared library in your current build configuration, but linking to the static one?

[CoffeeFlux]

Nothing, and setting the subproject to static will fix the issue with freetype specifically—I don't particularly care about the shared library when linking statically. The problem is more that I don't think I should have to go set the default_library manually for every single subproject that is building both by default. A lot of the time I want to link against the shared version, but for release builds on Windows I essentially want to say "link statically or die". Barring that, "link statically when both options are available" would be an improvement over the status quo.

[eli-schwartz]

Right, the general issue here has nothing to do with preferring static or shared and everything to do with subprojects currently being very suboptimal for people wishing to bundle fallback dependencies -- this, and several other issues, are due to subprojects being optimized for meta-projects that build and install a collection of projects at once.

This does need fixing, subproject fallback dependencies should default to static and also default to not installing the static library or headers etc.