[question] Is compiler.libcxx not part of package identification?

[h-2]

What is your question?

When switching from compiler.libcxx=libstdc++11 to compiler.libcxx=libc++, the binary packages in the cache of the CONAN_HOME are not rebuilt. This results in linking problems, because of ABI mismatch.

Is libcxx not used when determining the hash of package?

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[memsharded]

Hi @h-2

compiler.libcxx should be definitely part of C++ packages (it is removed in C packages).
You should be able to list it with conan list command and see their values. So there might be something else there. If you can please provide some more details so we can reproduce, that would help.

[h-2]

This was a local problem; sorry for the noise!

[memsharded]

No prob 🙂 !

[h-2]

Just to add to this: I have now switched from cppstd=20 to cppstd=23 and none of the packages are rebuilt. Instead I get

boost/1.83.0: Checking 9 compatible configurations
boost/1.83.0: Main binary package 'e21423fdd71e5fa8a537e8ce4d3c1165631c5648' missing. Using compatible package '79403b0c79a830fad4fe3a8b0870ba7242c2d856': compiler.cppstd=20

So C++20 and C++23 are considered ABI stable? Is this true for all packages or does it depend on the specific one? What if a library conditionally defines a function based on C++ standard?

[memsharded]

Yes, by default Conan assumes in the compatibility.py plugin default implementation that cppstd values are compatible. To change it you can customize your compatibility.py. Also we have #15348 for next release to allow easy per-recipe customization of default cppstd compatibility

[h-2]

Cool, thanks for the explanation!