Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [paho-dev] MQTT C Shared Library Names

On Linux will you use the standard shared library naming convention? With current and .major soft links to the specific .major.minor library file?

I highly recommend it. It insures compatibility with multiple versions, and the linker already supports it.

In that case, you wouldn't need the version in the base name. You would have:     [soft link, pointing to...]   [soft-link, pointing to...] [actual library file]
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 [] 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 => /home/fmp/mqtt/mqttpp/src/samples/../lib/ (0x00007fc2f0004000)


On 10/31/2013 11:34 AM, Ian Craggs wrote:

There are plenty of examples of longer library names on my system:

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:


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.


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?

On Thu, Oct 31, 2013 at 2:22 PM, luja <luja@xxxxxxxxxxxxxxx> wrote:
Hi all,

good idea, but keep it short,

keep it short, omit vovels like hebrews do :-)



On 10/31/2013 3:08 PM, Ian Craggs wrote:
> Hi All,
> currently the shared library names are libmqttv3 plus suffixes:
> c - synchronous, non-SSL
> cs - synchronous, SSL
> a - asynchronous, non-SSL
> as - asynchronous, SSL
> On Windows, they are mqttv3c.dll ...
> I was thinking that they should have paho in the names, for "brand"
> identification.  If they do end up in Linux distributions, or
> otherwise distributed, this may be necessary to avoid clashes in any
> case.
> So...
> libpahomqttv3c
> and
> pahomqttv3c.dll
> ?
> Thoughts?
> Ian
> _______________________________________________
> paho-dev mailing list
> paho-dev@xxxxxxxxxxx

paho-dev mailing list

Andy Piper | Kingston upon Thames, London (UK)
blog:   |   skype: andypiperuk
twitter: @andypiper  |  images:

paho-dev mailing list

paho-dev mailing list

Back to the top