Community
Participate
Working Groups
Shared libraries on Linux and similar systems are expected to have a version number, e.g. libmqttv3c.so.1 rather than libmqttv3c.so. If binary incompatible changes are made to the library the first major number is incremented, libmqttv3c.so.2.0.0. Strictly speaking the following is true, but not always implemented. If a new version is released that is compatible, the second version number is incremented libmqttv3c.so.1.1.0. Minor bugfixes are the final number. When the library is installed, a symbolic link is made for libmqttv3c.so.1 -> libmqttv3c.so.1.0.0 so that applications link against libmqttv3c.so.1 rather than a specific version and bugfix release. More information is available here for example: http://www.debian.org/doc/debian-policy/ch-sharedlibs.html In addition to the naming, during the linker step the soname of the library should be set. This can be done with the "-Wl,-soname,libmqttv3c.so.1" option to gcc.
Is the policy the same for all Linux distributions? We don't have an installation process at the moment, so I'm unclear at what point the symbolic link would be made. I would add that I don't intend there to be binary incompatible changes at any point, but accept the precaution and convention of versioning.
All the major distros do it like this as far as I know. It's asking for trouble to do it any other way to be honest. If you don't have versioned libraries then it's not possible to have multiple incompatible versions installed at once. I'd have installation targets with something like this: install -s libmqttv3c.so.1.0.0 ${DESTDIR}${prefix}/lib${LIB_SUFFIX}/libmqttv3c.so.1 ln -sf libmqttv3c.so.1.0.0 ${DESTDIR}${prefix}/lib${LIB_SUFFIX}/libmqttv3c.so.1 I agree about the binary compatibility, but there's essentially no downside to having the versioned library once you've got the build scripts sorted. If there is an ABI break it's trivial to change the build scripts as well.
(In reply to comment #1) > Is the policy the same for all Linux distributions? We don't have an > installation process at the moment, so I'm unclear at what point the > symbolic link would be made. Usually that's done automatically by the package manager e.g. dpkg or rpm in the case of Debian and RH-based distros, respectively. We could certainly use an RPM .spec and apt config for the Paho C client.
Assigning to MQTT-C component
I've created a new Makefile in the root of the C project which versions the libraries according to this document http://l4u-00.jinr.ru/usoft/WWW/HOWTO/GCC-HOWTO-6.html on Linux. A version number which has just two components, major and minor, seems sufficient to me. Unless anyone wants to suggest otherwise. Hmm, I've used cp rather than the install command. Benefits to using install? Is there an uninstall? I'm planning to add a MacOS section to the Makefile, which can do the same or similar, and leave the operating system it at that for now (a Visual Studio project and Ant builds for Windows).
Benefits of install: You can create directories and copy the file in one operation using -D. You can set user/group ownership and permissions. You can strip debug information. Even if you aren't doing those it's the defacto standard way of copying compiled files to the system. I don't think it's hugely important. Personally I make all commands into variables so they can be changed easily if needed. One thing you should add is a .PHONY line for the targets that don't produce output, like all, mkdir, clean, ...
I've updated the Makefile in the master branch. 1) install used instead of cp 2) install-strip target added 3) MQTTVersion now built and installed 4) .PHONY target added I'm not overly happy about the list of install and rm commands in the install and uninstall targets, but the alternatives seemed just as complicated, unless you know better, Roger.
