Version 1.9.1 breaks BOOST library modules

[bredelings]

Starting with version 1.9.1, meson successfully "finds" BOOST on Debian even when the libraries specified in modules: are not installed. The result is that the compilation proceeds, but then fails at link time.

I would expect a message like the following from 1.9.0:

Run-time dependency Boost (found: json | missing: chrono, program_options, random) found: NO (tried system)

Instead I see:

Run-time dependency Boost (found: json) found: YES 1.88.0 (/usr)

This change seems to be the result of patch Check for header only Boost libraries. This patch seems to record components as present if their header files are present, without testing for whether their libraries are present.
However, this change effectively redefines what it means to be a boost "module". In 1.9.0 and prior, meson only allowed modules to be specified if there was a library to link to, and it would fail at configure time if these libraries were not installed.

I see that there is a follow-up patch that adds:

        must_have_library = ['boost_python']

Does this really work? If so, it seems like must_have_library would need to list all the boost components with libraries.

Maybe this change should be reverted for 1.9.2, and could then be explored more carefully for 1.10?

[thesamesam]

6a9a816 and 80917ca

cc @jpakkane

[jpakkane]

Grrrr. All of this is basically workarounds and busywork for the fact that Boost refuses to ship pkg-config files even though people have been requesting them for over 20 years now.

How could this be done reliably? The only one I can think of is basically "when looking up module X, try to also look up a library of the same name and use it if found". This fails if someone ships a library but someone uses the code in a header-only way (with magic defines). But is that rare enough that we don't need to support it?

[eli-schwartz]

How could this be done reliably? The only one I can think of is basically "when looking up module X, try to also look up a library of the same name and use it if found". This fails if someone ships a library but someone uses the code in a header-only way (with magic defines). But is that rare enough that we don't need to support it?

This should not break, if the library simply ends up unused because nothing actually uses its symbols. It will even be stripped out by -Wl,--as-needed.

If the magic defines cause the headers to expose the full implementation, no symbols are generated.

This change seems to be the result of patch Check for header only Boost libraries. This patch seems to record components as present if their header files are present, without testing for whether their libraries are present.
However, this change effectively redefines what it means to be a boost "module". In 1.9.0 and prior, meson only allowed modules to be specified if there was a library to link to, and it would fail at configure time if these libraries were not installed.

The implication here is that Debian ships the boost-json-dev packages etc for boost, which don't depend on the runtime components, and this is basically backwards compared to every other known dev package in the history of Debian? Can you elaborate on this because it is devastatingly confusing to me.

[bredelings]

Yes, it does seem like Debian ships all the include files in libboost1.83-dev. The package libboost-json1.83-dev then includes only libraries.

This has always worked fine because until now a boost "module" always meant a library-module. For example, when BOOST.system became header only, it continued shipping an empty library stub, and when they stopped shipping the stub I had to remove boost system from the list of modules in my meson.build. I think this broke on systems using cmake as well.

I haven't had any trouble with the boost dependency in meson before now. Can you clarify what problem these patches are trying to solve?

I could imagine that because the boost headers take up so much space that some packagers might not install headers for a header-only module. So then you might be trying to use the modules: argument to test for header-only module? This seems like an atypical setup though.

[jpakkane]

I could imagine that because the boost headers take up so much space that some packagers might not install headers for a header-only module.

Or that installing all headers in a single clump is easier. Separating each header into its own package is a lot of busywork, especially if they change often or have hidden interdependencies (which they almost certainly do).

[bredelings]

Or that installing all headers in a single clump is easier.

This is what we have already, and it was already working. So I don't understand why any changes were necessary.

[eli-schwartz]

If tracking interdependencies is hard then I can propose a novel solution: don't install broken stuff.

Don't provide individual boost-json-dev, and have it be a transitional package depending boost-dev.

Alternatively, make boost-dev depend on all packages providing the libboost_xxx.so symbolic links that are mandatory for using the files which boost-dev installs. But I don't see any advantage having just the symlink in a different package.

Boost in Debian today is simply broken, and for no obvious reason. It's a -dev package, depending on things that not all 100% of -dev package users need is okay.

Meanwhile the ONLY solution I can see for meson is for meson to contain a version-by-version list of boost modules that are exempt from needing a library component. Whenever a boost module transitions from being a library to being header-only, we add a min version. Whenever a boost module transitions from being header-only to being a library, we add a max version. Yes, this means boost users will need to wait for a new version of Meson every time boost upstream changes its approach.

This is not a workaround for upstream boost anymore, but rather a workaround for Debian. But such is life.

[bredelings]

Oh, I see. So you would really like Debian to put the header files for library modules into the dev package for the library. That makes sense. If that was the case, then presumably the changes that were made in 1.9.1 would work.

What I still don't get is what motivated this change in the first place.

[eli-schwartz]

Or that installing all headers in a single clump is easier.

This is what we have already, and it was already working. So I don't understand why any changes were necessary.

It is curious that you believe it was already working. Given you also said this:

This has always worked fine because until now a boost "module" always meant a library-module. For example, when BOOST.system became header only, it continued shipping an empty library stub, and when they stopped shipping the stub I had to remove boost system from the list of modules in my meson.build. I think this broke on systems using cmake as well.

I haven't had any trouble with the boost dependency in meson before now. Can you clarify what problem these patches are trying to solve?

... where in one breath you explain why it doesn't work, and clarify what problem these patches are trying to solve, and in the next breath you say you haven't had any trouble with the fact that it doesn't work, and ask for clarification on the thing you yourself clarified! :)

(Okay okay okay, yes, what you're actually saying is that the boost experience is bad but you believe that's okay because, I suppose, it is a problem with CMake also. Still, you do realize that your meson.build is apparently now specific to given versions of boost?)

I could imagine that because the boost headers take up so much space that some packagers might not install headers for a header-only module. So then you might be trying to use the modules: argument to test for header-only module? This seems like an atypical setup though.

Well, less that and more "trying to find a library module for one version of boost, and the same module even if it's header only in another version of boost".

[bredelings]

OK, I think I understand what you are trying to solve now. Handling libraries that change from library to header-only seems challenging given how boost has responded to requests for pkg-config files in the past.

This might be a good time to bring this issue up again. The Boost project seems to be undergoing some degree of reorganization. This seems to include some changes in governance, hosting infrastructure, and also some new money to pay people to fix problems with Boost. So perhaps I will try.

When this issue last came up in 2017, it seems like one of the sticking points was that boost has a lot of "variants" -- e.g. single-threaded versus multithreaded, debug versus non-debug, etc. Another issue is that there would need to be a pkg-config file per module... but I don't really seem the problem with this. On Linux these don't seem important, but I guess they are on windows? Boost seems oddly windows focused.

The other thing that has changed is that boost now ships cmake files to find boost. This is annoying package-manager-specific... but perhaps meson could use this, since it has a cmake interpreter.

In summary, given that boost seem to have (i) somewhat more manpower and (ii) more interest in making people WANT to use boost, its possible they would be open to something. I see that Jonathan Wakely proposed a script that could be used to get config options, if for some reason boost people refuse to think about pkg-config.

P.S. See this BOOST blog post on packaging for conan: https://cppalliance.org/dmitry/2025/10/16/dmitrys-q3-update.html

P.P.S. Note that developers being paid to work on boost are writing "updates".

[eli-schwartz]

When this issue last came up in 2017, it seems like one of the sticking points was that boost has a lot of "variants" -- e.g. single-threaded versus multithreaded, debug versus non-debug, etc. Another issue is that there would need to be a pkg-config file per module... but I don't really seem the problem with this. On Linux these don't seem important, but I guess they are on windows? Boost seems oddly windows focused.

The other thing that has changed is that boost now ships cmake files to find boost. This is annoying package-manager-specific... but perhaps meson could use this, since it has a cmake interpreter.

The cmake files are 3 files per module, so if that is their objection pkg-config will be an improvement.

Boost variants are a bit odd. They treat static / shared as different variants but pkg-config does not need that clumsiness. Multithreading is also a variant, as is "debug runtime". But I believe those are Windows quirks. :)

[bredelings]

I did some internet searching, and it seems that the strategy here works for

• Suse

But it fails for the following Linux distributions:

• Debian + Ubuntu
• Red Hat
• Arch
• Gentoo
• Alpine

I've only actually tested on Debian.