At Tue, 22 May 2018 12:51:49 -0700 "Paul B. Henson" <[email protected]> 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 [email protected] -- Webhosting Services
