Repository navigation
Subproject links against dynamic library when building both despite -Ddefault_library=static #8047
Description
Activity
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.
@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')
default_library is a per subproject setting and doesn't inherit from the parent project.
I realize that
default_libraryis set per-subproject, butbothis 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_libraryspecifies 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.What's the general use case of building a shared library in your current build configuration, but linking to the static one?
Nothing, and setting the subproject to
staticwill 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 thedefault_librarymanually 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.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.
Reacted by Tristan Partin, Xhivo and EBK21I think the solution that has been proposed in the past is to add a way to set an option for all subprojects.
-Dsubprojects:default_library=staticwhich would cause all subprojects to be static while main project is still shared.I don't think we should change the default as that's not backward compatible, and is just arbitrary. Some people, or use-case, prefer static, others prefer dynamic, that's fundamentally a user choice and not a Meson or project choice.
Also, not installing subprojects static libraries would make main project static libraries unusable. Again, that's fundamentally a user choice to only need runtime files, that can be done with
meson install --tags runtime.
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 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