c++conan-2

Can I tell Conan about which GLIBCXX versions are supported in my environment?

I am using Conan (version 2.15.1) to install Boost in a Debian Bullseye Docker container. I am able to do that successfully with the command conan install --build "*" . (build everything from source). However, if I use the command conan install --build missing . (build packages from source whose binary package is not found) I get the following error:

b2: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by b2)
boost/1.81.0: ERROR: 
Package '05dfec083bf58cba12a79d642bb5802f477d797e' build failed
ERROR: boost/1.81.0: Error in build() method, line 1167
        self.run(full_command)
        ConanException: Error 1 while executing

This error suggests to me that Conan downloaded a binary package that is not actually compatible with my environment. I am currently using the auto-detected profile which looks as follows:

[settings]
arch=x86_64
build_type=Release
compiler=gcc
compiler.cppstd=gnu14
compiler.libcxx=libstdc++11
compiler.version=10
os=Linux

Is there a way that I can tell Conan about which GLIBCXX versions are supported in my environment? Is there a profile setting that I am overlooking? It's perfectly acceptable if ConanCenter doesn't have a compatible binary and the package needs to be built from source. My reason for wanting to switch from --build "*" to --build missing is because the former rebuilds from source on all subsequent builds when a previously built binary is available in the local cache, which is undesirable.

Solution

  • There were some discussions about this issue:

    And couple more around the same issue and ideas.

    If you have a persistent local cache (like, not a single-shot CI containers) as it would seem from the question, you should be able to just rebuild b2 on your machine and be done with it. Once "proper" locally-built working binary is in your cache, it would be used for subsequent builds.

    For a more "enterprisey" solution (as in, working with CI and multiple dev machines)... we have on-premises Conan binary repository (as well as vendored recipe repository instead of directly feeding off CCI). All the "tool" recipes like b2 are built using the oldest distro we have (which has minimal ABI versions of all the system libraries between all of our supported "target" distributives) and then uploaded to the repository. Not a "proper" solution but it was a quick way to deal with this issue.

    More proper solution would be to add a setting for OS distro and its version ("Ubuntu 22.04") so that tools built on a particular distro can only be used when building something on the same distro. That would solve the usual case of native compilation; for cross-compilation though it wouldn't work - for that one would have to introduce additional settings in the profile for build OS.

    EDIT: I don't have a ready-available solution for the latter approach. You can do it fairly easily manually by adding custom settings like described in https://docs.conan.io/2/reference/config_files/settings.html . That requires manually setting correct distro version for each Conan installation which is not ideal. Profiles are Jinja templates though (https://docs.conan.io/2/reference/config_files/profiles.html#profile-rendering), so you can probably come up with a single profile template using platform.freedesktop_os_release(), or something like that. If you use this approach by adding additional sub-settings to os, those settings will affect os setting and any package with os in its settings list will get separate binaries for each distro (which probably is overkill for most library-type packages that get enough distinction from compiler/libstd settings, but it wouldn't hurt either). https://github.com/conan-io/conan/issues/1093 talks about the same some more.