My knowlegde is quite limited in this area. I’ll try to answer, but keep that in mind when you read the below.
Basically, the idea is that if a Linux distro (or whatever package manager like MacPorts or Anaconda) includes package
A that depends on library
1.2, then it should be safe to update only package
B (the binaries) from e.g. version
1.2.4 without having to recompile package
A (and all other packages that depend on
ABI compatibility, or binary compatibility, means that you can upgrade or downgrade a binary package without breaking its dependents.
API compatibility, or source compatibility, means that
A should compile with any
1.2.x version of
B, but not that an already compiled
A can link to any already compiled version of
As we have seen in more than one GitHub issue, distro maintainers don’t like duplication. They prefer packages not to embed libraries, but to link to it dynamically. Unless I misremember, there were also suggestions that python-igraph should link dynamically, not statically to igraph in conda? If it did that, binary compatibility would become a serious concern. There’s one good reason to just link statically.
Some projects explicitly guarantee and and consider any breakage a bug. E.g., here’s the statement by Qt: https://wiki.qt.io/Qt-Version-Compatibility
Some don’t. See trouble here: https://github.com/mpv-player/mpv/issues/5187
This is not easy to test as breakages tend to be subtle. In my opinion, the fact that our tests pass is a rather weak evidence that nothing broke, when it comes to binary compatibility. Just think about the Python situation on Windows: you’re supposed to use a specific compiler for each Python version. If you don’t, things will probably work just fine … unless you get very unlucky and hit on that special edge case.
Considering the effort, I don’t think it’s worth bothering with it. We’re not Qt and don’t have their resources. Also, I’d hope to be able to contribute to igraph primarily as a scientist who programs (which I consider myself to be), not as a programmer who knows something about network science and graph theory
tl;dr No, in most cases you do not need to know what compiler will be used to be able to maintain reasonable binary compatibility. You just need to avoid certain kinds of changes in the source code.
Compilers, and even compiler versions, are not always ABI-compatible. Something compiled on a newer Linux (new gcc) won’t always run on an older Linux (old gcc). Right now I compile IGraph/M on Ubuntu 16.04 with
-D_GLIBCXX_USE_CXX11_ABI=0 to ensure compatibility with some older systems such as RHEL 7 … But I’ll admit that I’m really doing cargo cult programming here …
This is one dimension of ABI compatibility: two libraries must be compiled with the same (or explicitly compatible) compilers if they are to be linked together. This is one unpleasant aspect of creating binaries that work for everyone on all OS versions … But this is not the issue we’re discussing here.
The question now is: if we make a change to the source code, can that break ABI compatibility without breaking API compatibility, provided that the compiler didn’t change? Yes, a simple example is if the integer codes assigned to enum values change. The API is the same, as we use names in the source code. But the underlying numbers have changed. Another example would be if we add a new field to a
struct. The old fields are still there, old source code is compatible. But the offset where this field is stored has now changed: the underlying representation is different.
I guess what you are asking here is: is there a kind of source change that breaks ABI compatibility only when using compiler X but not when using compiler Y? I’m sure the answer is yes, but this goes beyond my knowledge and I cannot give a realistic example I do recall that in the previous version of Raspbian I kept getting warnings like this, which I think indicate a similar situation: https://github.com/catchorg/Catch2/issues/1323 (I seem to recall reading that the issue was present only on ARM, so in that sense yes, it is w.r.t a specific architecture).