[question] ABI incompatibility although `compiler.version` matches

[pasbi]

I'm building a library that uses spdlog.

My conan profile:

[settings]        
arch=x86_64
build_type=Release
compiler=msvc
compiler.cppstd=20
compiler.runtime=dynamic
compiler.version=194
os=Windows

According to https://conan.io/center/recipes/spdlog, spdlog/1.16.0 was build with the same compiler.version=194.

But I get a linker error:

spdlog.lib(spdlog.cpp.obj) : error LNK2019: unresolved external symbol __std_find_first_of_trivial_pos_1 referenced in function "unsigned __int64 __cdecl std::_Find_first_of_pos_vectorized<char,char>(char const * const,unsigned __int64,char const * const,unsigned __int64)" (??$_Find_first_of_pos_vectorized@DD@std@@YA_KQEBD_K01@Z) [C:\conan\p\b\foofe610ddef6d95\b\build\src\foo.vcxproj]

When I require some option for spdlog such that conan is forced to build the package locally, it links fine (FTR, I asked for {"no_exceptions": True}).
My local MSVC version is 19.44.35209.

What is your question?

• compiler.version=194 matches any of 19.40, 19.43, 19.44, 19.49, right?
• Is it possible that there was a breaking change from whatever conancenter-spdlog/1.16.0 was build to my 19.44? It wouldn't be possible to catch this if only the first three digits are used for compiler identification.
• Maybe the problem is that spdlog/1.16.0 in the conan center was build with C++14 and I use C++20?

I appreciate any help, thanks!

[jcar87]

Hi @pasbi, thanks for your question.

Conan Center CI is currently using 19.44.35213.0, slightly newer than the one you are reporting.

Unfortunately and as per https://learn.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017?view=msvc-170 - linking is only guaranteed to work with backwards compatibility,

The key rule is that the linker should only work with inputs built by build tools that are the same version (or earlier) as itself.

Since you're bringing in binaries built with 19.44.35213.0 , which is slightly newer than 19.44.35209 , there is a chance this could be the reason behind the errors.

compiler.version=194 does match all the 19.4x - Conan can model the next number with compiler.update, however in this case both seem to be 19.44...

Maybe the problem is that spdlog/1.16.0 in the conan center was build with C++14 and I use C++20?

This is also possible - although it would be a bit unexpected of msvc to cause this on its own (compilers tend to be ABI compatible across multiple c++ standard levels..), would need to cross check with the spdlog source code

[pasbi]

Thanks for the reply!

Isn't compiler.version supposed to prevent such binary incompatibility issues?
Isn't it a fundamental design flaw in compiler.version to treat two incompatible compiler versions as equivalent?
I would expect Conan to only get packages that are compatible according to the link you've posted.

What are the practical implications?

• I need to ensure to have a more recent version than the Conan CI (or whoever else builds the package I want to use), i.e., I have to monitor the Conan CI configuration or react to every MS release to catch all potential Conan CI upgrades. I guess that's not feasible from my side.
• Only consume packages that are compatible. But how should I now? I'd expect compiler.version to tell me, but apparently it's not sufficient.
• Build problematic packages (better: all packages) myself, but that's a bit against the design of Conan and, AFAIK, only possible with awkward workarounds (here: requiring an exotic option I don't actually care about to force Conan to build the package locally).

I hope I missed something and there is a proper way to solve this 😄

[jcar87]

Isn't compiler.version supposed to prevent such binary incompatibility issues?

It's a compromise.
For msvc, we do have the compiler.update subsetting to model the number that comes after the 19x -
for instance, you can have:

compiler.version=194
compiler.update=4

to model 19.44

However, here we are dealing with the number that comes next. The are 20 (probably 21) Visual Studio 2022 releases in the 17.14 series as per the following list: https://learn.microsoft.com/en-us/visualstudio/releases/2022/release-notes?tabs=allfeatures

Microsoft does not seem to document which exact version of the Visual C++ compiler comes with each update (if you find this please let us know! )

They do seem to move on quickly and no longer support older "minor" versions - with only a subset of older versions supported:

but here we are both dealing with 14.44 toolset, from the 17.14 series, with the 19.44 compiler ...

The current solution is a compromise for broad compatibility: given the number of releases for the 194 version (17.10, 17.11, 17.12, 17.13 and 17.14) as well as the patch releases for each of those (each of those has between 6 and 20 patch releases, and each can come with a version of the compiler) - if we model the compiler to the exact version, our binaries would not really be usable by a lot of people: what we would expect is that most users just keep Visual Studio up to date by running the Visual Studio installer a few times per year.

Installing specific older versions is also not straightforward: one must first fully uninstall Visual Studio and then download a bootstrapper for the specific version from here: https://learn.microsoft.com/en-us/visualstudio/releases/2022/release-history#uninstalling-visual-studio-to-go-back-to-an-earlier-release
One can install a toolset from a still supported LTSC version, but that will likely be the most recent update available for it.

I need to ensure to have a more recent version than the Conan CI (or whoever else builds the package I want to use)

I'd say it's a lot easier than this. It doesn't matter what version Conan CI uses - if you keep Visual Studio up to date, it will work.

[pasbi]

Thanks for the thorough reply.
This was a very interesting read and I think I understand the dilemma.

I'd say it's a lot easier than this. It doesn't matter what version Conan CI uses - if you keep Visual Studio up to date, it will work.

Sure, that works because MSVC is backward compatible (for now?).
In practice, that's a major issue, however:
Every VS upgrade is tedious manual work and potentially breaks our CI (causing downtime and even more manual work to fix it).
There's mostly no reason to update a few times a year other than compatibility, so it's hard to justify.

if we model the compiler to the exact version, our binaries would not really be usable by a lot of people:

I understand: Conan wants to distribute binary packages by default and only build it locally as a fallback.
For my use case, I don't see a problem in building all packages locally.
They don't change very often, so even huge packages like OpenCV or Qt won't be an issue.
It's a price I'd be willing to pay to get guaranteed compatibility.

Do you consider an "always build locally"-option?

The most alarming thing is that all these incompatibilities could have catastrophic consequences without anyone noticing.
If yesterday MSVC decided to release a new release and Conan CI switches to that new release today, I might not even have the time to react. After all, our CI is supposed to run in background.
And ABI-incompatibilities don't need to result in linker errors, they could just silently do something unexpected with potentially catastrophic result for the user of the resulting binary.

I really appreciate your feedback.
IMHO, there must be a way to at least gracefully fail building a package if binary compatibility cannot be guaranteed.
Otherwise the whole concept of a binary package manager is absurd.

[jcar87]

Sure, that works because MSVC is backward compatible (for now?).

The v14x toolsets of Visual Studio are guaranteed to be backwards compatible. When they release a version that isn't - then Conan won't assume they are compatible either.

Every VS upgrade is tedious manual work and potentially breaks our CI (causing downtime and even more manual work to fix it).

indeed this will depend on how your infrastructure is set up - this is not our experience either way (neither our ability to upgrade, nor do we see widespread breakages. Occasionally, some recipes may fail to build with newer versions - we endeavour to fix them because if we see those issues that means our users may see it - bit if we didnt have that concern, this isn't a big issue. Visual Studio supports installing older toolsets side-by-side, so we can just fall back to that (with a 2 line change in the Conan profiles if needed)

Do you consider an "always build locally"-option?

You can edit Conan's remote configuration and set the Conan Center remote to be recipes_only. Then Conan will never consider binaries from Conan Center (you'd have to build them locally, or have them in a remote maintained by you).

IMHO, there must be a way to at least gracefully fail building a package if binary compatibility cannot be guaranteed.
Otherwise the whole concept of a binary package manager is absurd.

There's mostly no reason to update a few times a year other than compatibility, so it's hard to justify.

as much as I would otherwise agree - and given that we do maintain a similar system with similar concerns, I'd say you are probably a tad "too" conservative when it comes to staying on old Visual Studio. Given the strong guarantees that it is backwards compatible, I'd say that not on a supported version (as per Microsoft guidelines) is a very strong motivator to update however many times a year necessary.

Github actions is also kept up reasonably up to date (https://github.com/actions/runner-images/blob/main/images/windows/Windows2025-Readme.md#visual-studio-enterprise-2022) - any binaries built on it would impose similar constraints on users.

IMHO, there must be a way to at least gracefully fail building a package if binary compatibility cannot be guaranteed.
Otherwise the whole concept of a binary package manager is absurd.

On top of marking the Conan CEnter remote as a recipes only remote - you can also use a custom version (in your settings.yml) for the compiler, that captures the exact version - but note that unless you use those specific installer bootstrappers from Microsoft, it's actually hard to guarantee that everyone is on that specific version - each different machine will be on a different version depending on what was available when it was installed.

[jcar87]

also note, that I'm not sure this is the specific cause of the error you are reporting - since both are version 19.44
The only way to confirm is to use a newer version and see if it fails in the same way.

[pasbi]

also note, that I'm not sure this is the specific cause of the error you are reporting - since both are version 19.44
The only way to confirm is to use a newer version and see if it fails in the same way.

I agree, but frankly speaking, it's a matter of principle. I mean, I was able to work around the actual issue last week already.
I want to understand what's happening.
You have done a fantastic job explaining that. Thank you!

You can edit Conan's remote configuration and set the Conan Center remote to be recipes_only.
I will give this a try. Sounds promising.

as much as I would otherwise agree - and given that we do maintain a similar system with similar concerns, I'd say you are probably a tad "too" conservative when it comes to staying on old Visual Studio. Given the strong guarantees that it is backwards compatible, I'd say that not on a supported version (as per Microsoft guidelines) is a very strong motivator to update however many times a year necessary.

No, I need a version with "guaranteed ABI compatible", not just as "supported per MS guidelines".
Only the very latest release brings the guarantee that there is no binary package built with a newer one.
So I have to upgrade immediately whenever MS relases.
Every moment of delay is a potential ABI problem.

I'd be fine if someone else managed the MSVC upgrades.
I have no problem working with latest MSVCs.
Just, I'd need to do it myself and I have better things to do.

Maybe it's worth to put a warning in the docs?

Anyway, I understand the issue and I understand that Conan cannot really solve this due to MS update policies.

Thanks again for the explanations, really appreciate <3