Re: [paho-dev] MQTT C Shared Library Names

[Frank Pagliughi <fpagliughi@xxxxxxxxxxxxxx>]

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:

libpaho-mqtt.so     [soft link, pointing to...]
libpaho-mqtt.so.3   [soft-link, pointing to...]
libpaho-mqtt.so.3.0 [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 [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?

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

Hi all,

good idea, but keep it short,
ph....
phmqttv3c.dll
libphmqttv3c

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

cheers,

luja

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
> https://dev.eclipse.org/mailman/listinfo/paho-dev
>

_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/paho-dev

--

Andy Piper | Kingston upon Thames, London (UK)
blog: http://andypiper.co.uk   |   skype: andypiperuk
twitter: @andypiper  |  images: http://www.flickr.com/photos/andypiper

_______________________________________________
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