The convention also makes it so that
a bug fix version with no changes to the API would be a minor
upgrade [.so.3.0 to .so.3.1] and that file should replace the
old one, including updating the .major link file to point to the
new library.
Any change of the API would constitute a major change [.so.3.x
to .so.4.0]. That new shared library would exist side-by-side
with the old version so older apps could still use it.
The neat thing is that you link to the current version as
specified by the top-level shared object [libpaho-mqtt.so] but
the linker actually attaches to the .major version so that the
app "sticks" to the proper library, even after a system upgrade.
So there's no "DLL Hell" on Linux if you use this convention,
but neither do you need to link against a specific version. The
default soft-link takes care of of it.
Look at the Makefile for the C++ library. I did (an admittedly
primitive) version of this.
Oh, and then the 'ldd' command will tell you which .major
version the app is tied to:
$ ldd async_publish
libmqttpp.so.0 =>
/home/fmp/mqtt/mqttpp/src/samples/../lib/libmqttpp.so.0
(0x00007fc2f0004000)
...
Frank
On 10/31/2013 11:34 AM, Ian Craggs wrote:
There are plenty of examples of longer library names on my
system:
libQtDesignerComponents.so.4
and you hardly ever have to type them in, so a longer name
doesn't seem to be a problem to me. In fact, in common with
some other names, we could add a dash:
libpaho-mqttv3c
We probably don't need the v3 part, although I quite like it.
If there were ever a v4 then that could have a v4 suffix. I'm
thinking that the OASIS standard behaviour would be obtained
with the same library using a flag in the connect options.
Ian
On 31/10/13 14:47, Andy Piper wrote:
I actually think maintaining the whole "paho"
is important here so people have a chance of finding us from
a Google search based on filename. I wonder if we need the
"v3" part though?
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/paho-dev
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/paho-dev
