shared library soname is poor

[loveshack]

I haven't had a chance to look into this more and try to fix it, but there's a problem with how the shared library is named. The version in the soname should reflect the ABI, not the software release numer, as it seems to. The ABI has changed incompatibly, but the .so.1.6 library gets linked to .so.1, the same as for the incompatible .so.1.5. It needs to be .so.2.something instead.

(Looking at the ABI differences between rpms of 1.5 and 1.6, I see differences in some specific ...avx2... and ...avx512... functions and wonder whether they're mean to be exported, but haven't tried to check.)

[hfp]

Hi Dave,

I think we only adhere softly to ABI/binary compatibility from version to version. This is still an emerging and fast moving project. I have to say this since it's also not tested. In turn, claiming such conformance really requires at least some tests that cover this claim.

We of course have the intention to only break deployed integration, when the Major version is incremented (this will also be noted in the release notes). For recently introduced code, we may also break compatibility when the Minor version number is incremented (it is very likely that this will be noted in the release notes). Version 1.6 is an example for the latter (minor version incremented, but ABI breaks [only for the new DNN API!]). The "Update" and "Patch" part of our version components are supposedly binary compatible.

We also do not mark functions as "noexport" (or similar) right now. So we have a larger "ABI" then what we actually document and support. The functions that you mention belong to our internal ABI (src folder), and we may break it any time. As I said, we have an "internal" interface, and an "external" interface. The latter should not only be documented but basically consists of "publicly exposed" header files (include folder).

We also support "header-only" for C and C++, which I believe is pretty unique and rare technology given that our code may contain Intrinsics that require to instruct the compiler to enable such code path. You can read about how we love "header-only" (https://github.com/hfp/libxsmm/blob/master/scripts/libxsmm_source.sh#L58). The header-only support requires the user to avoid using any internal/undocumented function (or to request official support for it).

Anyhow, I will look into the soname issue, and see if it can be improved.

Hans

[hfp]

Added a statement: https://github.com/hfp/libxsmm/wiki/Q%26A/_edit#is-libxsmm-compatible-from-version-to-version-or-what-is-the-abi-commitment.