Re: .so version numbers for dlopen'd objects

[Robert Heller <heller@deepsoft.com>]

At Tue, 22 May 2018 12:51:49 -0700 "Paul B. Henson" <henson@acm.org> wrote:

> 
> I'm trying to get the OpenBSD openldap port updated to use modules,
> currently it just builds everything into a monolithic binary. They are
> objecting to the existence of the version number in the shared objects for
> the modules:
> 
> -rwxr-xr-x 1 henson henson 1773576 May 21 12:54 back_bdb-2.4.so.2.10.7
> -rwxr-xr-x 1 henson henson     864 May 21 12:54 back_bdb.la
> lrwxrwxrwx 1 henson henson      22 May 21 12:54 back_bdb.so ->
> back_bdb-2.4.so.2.10.7
> 
> They say that shared objects which are intended to be dlopen'd, as opposed
> to linked to, should not include version numbers, and it should look like:
> 
> -rwxr-xr-x 1 henson henson 1773576 May 21 12:54 back_bdb-2.4.so
> -rwxr-xr-x 1 henson henson     864 May 21 12:54 back_bdb.la
> 
> What is the openldap developer perspective on this?

I am not an openldap developer, but do develop other projects that use dlopen 
(specificly Tcl extensions).  If using libtool, it *should* create symlinks 
for the .so file without the version numbers like this:

sauron.deepsoft.com% dir Deepwoods/ModelRRSystem/BUILDS/Linux64/C++/Azatrax/.libs/
gettext.o       libazatrax_la-Azatrax.o       libazatrax.so@
libazatrax.a    libazatrax_la-azatrax_wrap.o  libazatrax.so.0@
libazatrax.la@  libazatrax.lai                libazatrax.so.0.0.0*

In my case, the shared library is *both* a dlopen'ed tcl extension and can 
also be linked to by a C++ program.  This is under Linux, but I do the same 
under MacOSX (which is an OpenBSD variant under-the-hood).


> 
> Thanks.
> 
> 
>                    

-- 
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
heller@deepsoft.com       -- Webhosting Services