[CMake] How to build fully correctly versioned shared object files with cmake

Hendrik Sattler post at hendrik-sattler.de
Mon Aug 6 15:54:33 EDT 2018



Am 6. August 2018 20:27:23 MESZ schrieb Philip Van Hoof <philip at codeminded.be>:
>Hello everyone,
>
>I noticed that it sometimes happens that I find a package for a shared
>object file(s) (or DLLs, on platforms like Windows) that have a build
>set up using cmake, that doesn't set everything that should be set.
>
>Usually as packagers of various popular open source softwares correct
>enthusiasts' attempts at understanding the sometimes bizarre
>complexities of for example autotools, but (although it's all less
>complicated) also cmake, it ends up somewhat right. Somewhat. I noticed
>that especially in corporate world, things tend to go spectacularly
>wrong. Almost without exception.
>
>In particular am I concerned about ABI versioning of shared object
>files so that they are easy to package and distribute by various
>operating systems (like, among others, Linux distributions). But also
>API versioning of development files (compiler header files and pkg-
>config) and installing to the right installation paths.
>
>I wanted to invite the community to scrutinize some equivalent examples
>that I made for autotools (with libtool), qmake, cmake and meson.
>
>https://github.com/pvanhoof/dir-examples/
>
>In particular I wanted to invite the cmake community to take a look at
>this example:
>
>https://github.com/pvanhoof/dir-examples/tree/master/cmake-example
>
>The idea is that the examples are as correct as possible. That means
>the examples should simple and educational. Easing (some amount) of
>platform independence (ie. supporting Windows) and packaging.

Is there ANY reason to use libtool library versioning? It might surprise people but it really is not any kind of standard.

Just change the SOVERSION when you make incompatible ABI changes and a normal library VERSION. There's really not more to it, especially nothing like the sick results that libtool produces, sometimes.

The difficult thing is to realize the need for such a change. But there are tools that can help.

>ps. I don't think CC-ing a huge amount of mailing lists is necessarily
>a good idea. So feel free to forward to the appropriate people.
>
>ps. I attached no license to the examples yet. Perhaps I should attach
>one? My goal would be that as much entities could copy and use it.
>Including for, indeed, non-free purposes (as much as they want).
>
>
>Kind regards,
>
>Philip Van Hoof


More information about the CMake mailing list