Building with autotools create libraries with version 0.0.0

Create issue
Issue #125 resolved
Feufochmar created an issue

When building the libraries with autotools, the libraries are created with the version 0.0.0 (ex: libtcod.so.0.0.0), instead of the current version of the library (ex: libtcod.so.1.7.0).

This notably prevents simultaneous installation of different versions of the libtcod library on a system via "make install". Also, a binary linked against a previous version of the library cannot not see it is not binary compatible with the current version of the library, and could behave unexpectedly at execution, instead of raising a library link error, because the soname (currently set to libtcod.so.0) did not changed.

Comments (5)

  1. HexDecimal

    It's correct to do major.minor.patch with the so version? Or does it not really matter as long as the versions are unique?

  2. Feufochmar reporter

    For the name of the library on the disk, it's usually the full version major.minor.patch.

    For the soname (the library name with version stored inside the library for binary compatibility), it depends on your policy of binary compatibility between versions. For instance, if binary compatibility can be broken between minor versions but not patch versions (a binary compiled against 1.6.0 can be used without recompilation with 1.6.6, but not with 1.7.0), the soname should be libtcod.so.major.minor.

  3. HexDecimal

    So if I follow semantic versioning then I should use major:minor:0 for version-info.

    Right now I'm slightly stuck on how to parse the libtcod_version.h header from AutoTools. I'll figure it out eventually.

  4. Log in to comment