[question] How is Conan handling different C++ standard libraries? I'm interested in hardened libc++ specifically.

[HappyCerberus]

What is your question?

I want to build against a hardened version of libc++ (with container-aware iterators), so my first thought was that there surely must be a package for that.

There doesn't seem to be one. And from the documentation, I can't figure out how Conan handles different versions of libc++ or even libc++ vs stdlibc++.

So, how exactly does Conan handle the standard library dependency and hardened versions of the standard library?

Have you read the CONTRIBUTING guide?

• [x] I've read the CONTRIBUTING guide

[memsharded]

Hi @HappyCerberus

Thanks for your question.

The vast majority, like probably 99% rely on the compiler standard library. To select among different possibilities of the standard library, this is done via the compiler.libcxx=libc++|libstdc++|libstdc++11|... (it can have different values depending on the compiler, for example for qcc for QNX: libcxx: [cxx, gpp, cpp, cpp-ne, accp, acpp-ne, ecpp, ecpp-ne]

The Conan integrations will map this compiler.libcxx to different compiler or build system flags as necessary for the different build systems.

So it depends on how you need to inject your custom libc++. If it is just by name, it might be possible to add it to the settings_user.yaml, then, as the Conan builtin integrations probably will not recognize it, you might need to provide compilation flags injecting them via tools.build:cxxflags or maybe via a tools.cmake.cmaketoolchain:user_toolchain conf. Understanding how you would be passing the custom libc++ information to the different build systems would help.

[HappyCerberus]

@memsharded Well, I was hoping that Conan would manage this for me.

If I do it manually, then in Bazel I have to add a toolchain and then wrap it in a config. But of course then I can't use Conan at all (because a libc++ compiled with LIBCPP_ABI_BOUNDED_ITERATORS will not be ABI compatible).

[memsharded]

@memsharded Well, I was hoping that Conan would manage this for me.

Conan doesn't know about other user custom libc++ builds, how they would be modeled, their binary compatibility, etc. It is necessary to learn how this is expected to work, and how different compilers and build systems accept custom configuration of the stdlib, because not all compilers work the same.

If the ABI is not compatible, then it sounds that you need to add your custom one to settings_user.yml, to define exactly this difference in binary compatibility, that part is very straightforward, just add the name you want there and done, Conan package binaries will have a different package_id when you use compiler.libcxx=mycustomlibc++. The only thing that is a bit more challenging is knowing how such a custom libc++ is to be injected into the different compilers and build systems. If you wanted to define that to CMake or Autotools, how would that be done?

[HappyCerberus]

@memsharded OK, I will need to go and do some experiments. I wish the standard library was treated more like a package.

I would even like to express a dependency on a minimal version of libc++ or stdlibc++.

[memsharded]

OK, I will need to go and do some experiments. I wish the standard library was treated more like a package.

We know that there are users that are packaging their own custom stdlib in Conan packages. That is doable, and requiring it also doable, but likely that it would be more like a tool_requires, because is more like kind of the toolchain than a regular dependency library. The only non-automatic part is the consumption, because a stdlib is not something for example that CMake will find_package(mystdlib) and then target_link_libraries(mytarget ... mystdlib::mystdlib) because it is not a regular library.

We are looking forward your feedback, if there is something that can be improved in Conan to better support this use case, we are willing to know.

[HappyCerberus]

@memsharded I think I'm still missing something here. How would that work exactly?

Let's say I package libc++, both the production version and the debug version for development. I can't just magically inject that as a dependency to the packages that I didn't write, or can I?

I certainly do not want packages built against stdlibc++, or to re-use a package that was built against the debug version of libc++ when I'm building with the production version of libc++.

The technical side of things (how to feed it to the build systems) is one thing, but I'm struggling with the base design.

For example, if I'm building against libc++ on Linux, what happens with system packages? Since none of those will be compatible.