Different Gcc/clang versions

[bschindler]

Hi
This again is more of a question, or rather something that really confuses me about conan.
Gcc versions are in general compatible with each other. The abi does change, but it does so independently of the Gcc version (this is why conan needed to have the libstdc++11 entry after all). The C++ abi changed from gcc 3.x to 4.0 and it changed again for the C++11 abi.
So why does conan really consider gcc builds from different versions as incompatible? In general, even major version numbers are compatible (So I can take a 5.4 build and build a program and link against such a library using say gcc 6.3 or even 7.0). Now I understand that being defensive is generally a good practice. But isn't this taking it to the other extreme when also really requiring minor versions to be the same? 5.3, 5.4 etc are really just bugfix releases. Even if I cared about the major version used for a package (I certainly don't), for the minor, I will always want the newest available regardless of my local compiler.
Clang now also changed its version scheme such that the second digit denotes minor versions btw, so one might have to take this into account.

To summarize, my question is why conan does not try to fetch proper builds by making sure abi matches instead of checking compiler versions

[lasote]

Hi @bschindler,

Quick response: Conan doesn't try to be smart because it will fail, and it is worst than suppose that two different compiler versions are incompatible. And in our experience, making assumptions without having big convince of something, causes blocking and unexpected situations for the users.

Long response (not too long): But that doesn't mean that conan forces you to keep that default incompatibility, you have the full control of binary compatibility with the package_id method: http://docs.conan.io/en/latest/howtos/define_abi_compatibility.html

If it's annoying for you to declare that minor versions are always compatible we could provide a helper to invoke to set that behavior. We can think about it. Did you know about package_id() method?

[memsharded]

Hi @bschindler

Just to add more info:

not try to fetch proper builds by making sure abi matches instead of checking compiler versions

Basically, it is impossible to guarantee ABI compatibility for the general case. Too many different use cases, platform, compilers, etc.

Furthermore, a very important thing is that even if something could be ABI compatible, you still want to manage and use different packages for different compiler versions. Lets say that gcc 4.8 is forward ABI compatible with gcc 4.9. But it could be that the binary of gcc 4.9 can be faster because of (binary compatible) optimizations. Users can define that they want 2 different binaries, not just one (typically built with 4.8) because it is binary-compatible.

The approach followed by conan is to use some default settings (as compiler, compiler.version, architecture) that will work for a majority of users, and allowing full configurability of binary generation to users.

I think that with PR: #2084
And info from issue: #1214
And the cited docs: http://docs.conan.io/en/latest/howtos/define_abi_compatibility.html

There are no further actions, and we could consider this issue fixed. Please report or give feedback if you have further questions. Thanks!

[bschindler]

I think the action taken from the linked PR and the linked issue are reasonable and imo absolutely required. Forcing a package rebuild when switching from say gcc 6.3 to 6.4 is quite a pathological requirement. Making this requirement between gcc 5 and 6 or 7 - while not strictly required - is a defensive choice that I can certainly live with - so I'm happy to see that conan is moving in that direction. Yet:

Basically, it is impossible to guarantee ABI compatibility for the general case. Too many different use cases, platform, compilers, etc.

I'm coming from a gentoo background where gcc upgrades happen from time to time and they generally do not cause any package rebuilds. So assuming that I would develop an application using clang, it would not be uncommon to link against a C++ library which was linked with gcc 6 and another linked with gcc 5 (system installed, not conan). Its absolutely necessary for this to work as clang++ would only be usable on linux if the underlying system was compiled with clang as well which is not the case as we know. Yet, lots of people now happily use clang on linux on a daily basis with C++ dependencies installed from the distribution package manager.

What you really want to make sure is that if I ask for a package of a given version, is that I get a build that is actually compatible. The compiler version itself may be indicative, but it is a super weak guarantee. -fno-exceptions, -fno-rtti, libc++/libstdc++ and a few other switches are much more of a worry than the compiler version or even the compiler itself.
So, I do agree that defining compatibility is tricky and difficult. Its just that conan is very picky on the compiler and the version it "accepts", which in reality tends to be a much less problematic thing than the many ways compatibility can break without even changing the minor version of a compiler.

Furthermore, a very important thing is that even if something could be ABI compatible, you still want to manage and use different packages for different compiler versions. Lets say that gcc 4.8 is forward ABI compatible with gcc 4.9. But it could be that the binary of gcc 4.9 can be faster because of (binary compatible) optimizations.

Putting this in the package metadata for sure is an important thing to do. What I am criticizing here are the super strict requirements when packages are chosen/accepted.

[memsharded]

What you really want to make sure is that if I ask for a package of a given version, is that I get a build that is actually compatible

Yes, of course, this is what all of us want. But an automatic 100% guarantee of this is impossible, in our opinion.

So, I do agree that defining compatibility is tricky and difficult. Its just that conan is very picky on the compiler and the version it "accepts",

I am not fully sure what this means. Are you talking about the acceptance criteria for OSS packages in conan-center? Are you talking about the default settings? I am not sure which are the super strict requirements you mean, could you please clarify?

In any case, it would be better to propose suggested lines of actions to improve the current situation. In the same line that the gcc>=5 issue with the minors was pointed out, and we are glad to see it improved in conan, any other suggestion in the same line is more than welcome. Thanks!

[memsharded]

Usage of the major versions for gcc/clang is now the default. It seems no inmediate action necessary here, so closing this issue at the moment, though as I said, further suggestions for improvement are very welcome, just comment or open a new issue. Thanks!