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?
Thanks.
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.
From: Robert Heller Sent: Tuesday, May 22, 2018 1:16 PM
(specificly Tcl extensions). If using libtool, it *should* create
symlinks
for the .so file without the version numbers like this:
Yes, currently it both creates a .so.x.y file as well as a symbolic link from just .so, the assertion from OpenBSD is that for this use case there should only be the .so.
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).
OS X is actually based off of FreeBSD :). But all of the BSD's cross pollinate to some extent.
In this case, it is only a dynamically loaded module, I do not believe it is suitable or there would be a use case to link to it directly from an application. I don't really care myself, but it is one of the stall points keeping my changes from getting incorporated so I need to sort it out.
Thanks.
At Tue, 22 May 2018 17:20:57 -0700 "Paul B. Henson" henson@acm.org wrote:
From: Robert Heller Sent: Tuesday, May 22, 2018 1:16 PM
(specificly Tcl extensions). If using libtool, it *should* create
symlinks
for the .so file without the version numbers like this:
Yes, currently it both creates a .so.x.y file as well as a symbolic link from just .so, the assertion from OpenBSD is that for this use case there should only be the .so.
You can suppress the version numbers with the "-avoid-version" LDFLAGS option (I need to do this with the MS-Windows cross-build).
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).
OS X is actually based off of FreeBSD :). But all of the BSD's cross pollinate to some extent.
In this case, it is only a dynamically loaded module, I do not believe it is suitable or there would be a use case to link to it directly from an application. I don't really care myself, but it is one of the stall points keeping my changes from getting incorporated so I need to sort it out.
Thanks.
From: Robert Heller Sent: Tuesday, May 22, 2018 5:37 PM
You can suppress the version numbers with the "-avoid-version" LDFLAGS option
Cool, thanks for the pointer. Then the question is whether this is acceptable for upstream to deploy in general, or if I should just tweak the OpenBSD port to do so? Quanah or Howard :)?
Thanks.
At Tue, 22 May 2018 18:16:24 -0700 "Paul B. Henson" henson@acm.org wrote:
From: Robert Heller Sent: Tuesday, May 22, 2018 5:37 PM
You can suppress the version numbers with the "-avoid-version" LDFLAGS option
Cool, thanks for the pointer. Then the question is whether this is acceptable for upstream to deploy in general, or if I should just tweak the OpenBSD port to do so? Quanah or Howard :)?
It is the "standard" thing to do for a "shared module" (as opposed to a "shared library"). "Shared module" == something to be only ever opened with dlopen, while "shared library" is something a program is linked against (eg with ld, and then loaded when a process is launched and "linked" with the program loader (ld-so, et. al.).
Thanks.
On Tue, May 22, 2018 at 12:51:49PM -0700, Paul B. Henson wrote:
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
Personally I'd even go further:
-rwxr-xr-x 1 henson henson 1773576 May 21 12:54 back_bdb.so
(and no .la at all - on platforms where that's feasible)
From: Ryan Tandy Sent: Tuesday, May 22, 2018 5:56 PM
-rwxr-xr-x 1 henson henson 1773576 May 21 12:54 back_bdb.so
(and no .la at all - on platforms where that's feasible)
The documentation currently says to use the .la file:
http://www.openldap.org/doc/admin24/slapdconf2.html#cn=module
Although under linux I've always just used the .so file myself. Getting rid of the .la would require a documentation update and also possibly config changes for everybody who listened to the documentation :).
--On Tuesday, May 22, 2018 7:18 PM -0700 "Paul B. Henson" henson@acm.org wrote:
The documentation currently says to use the .la file:
http://www.openldap.org/doc/admin24/slapdconf2.html#cn=module
Although under linux I've always just used the .so file myself. Getting rid of the .la would require a documentation update and also possibly config changes for everybody who listened to the documentation :).
The admin guide contains examples, is not authoritative, and may not apply to all cases (For example, statically built modules wouldn't work with the config you noted). The manual pages are the authoritative documentation, and they explicitly allow for either the .la or .so files:
moduleload <filename> Specify the name of a dynamically loadable module to load. The filename may be an absolute path name or a simple filename. Non- absolute names are searched for in the directories specified by the modulepath option. This option and the modulepath option are only usable if slapd was compiled with --enable-modules.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
From: Quanah Gibson-Mount Sent: Tuesday, May 22, 2018 8:14 PM
The admin guide contains examples, is not authoritative, and may not apply to all cases (For example, statically built modules wouldn't work with the config you noted). The manual pages are the authoritative documentation, and they explicitly allow for either the .la or .so files:
Unless I'm missing something, this documentation doesn't mention any extensions :). So technically it allows for arbitrarily named modules ;).
In any case, that's a bit of a tangent; what do you think about the main question, no longer including the so version number in the installed modules? So:
-rwxr-xr-x 1 henson henson 811 May 22 18:41 accesslog.la -rwxr-xr-x 1 henson henson 151064 May 22 18:41 accesslog.so
Just the la and so with no additional so symbolic links?
moduleload <filename> Specify the name of a dynamically loadable module to load. The filename may be an absolute path name or a simple filename. Non- absolute names are searched for in the directories
specified
by the modulepath option. This option and the modulepath option are only usable if slapd was compiled with --enable-modules.
--On Wednesday, May 23, 2018 1:24 PM -0700 "Paul B. Henson" henson@acm.org wrote:
From: Quanah Gibson-Mount Sent: Tuesday, May 22, 2018 8:14 PM
The admin guide contains examples, is not authoritative, and may not apply to all cases (For example, statically built modules wouldn't work with the config you noted). The manual pages are the authoritative documentation, and they explicitly allow for either the .la or .so files:
Unless I'm missing something, this documentation doesn't mention any extensions :). So technically it allows for arbitrarily named modules ;).
In any case, that's a bit of a tangent; what do you think about the main question, no longer including the so version number in the installed modules? So:
-rwxr-xr-x 1 henson henson 811 May 22 18:41 accesslog.la -rwxr-xr-x 1 henson henson 151064 May 22 18:41 accesslog.so
Just the la and so with no additional so symbolic links?
I think Howard already answered that question. ;)
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Paul B. Henson wrote:
From: Ryan Tandy Sent: Tuesday, May 22, 2018 5:56 PM
-rwxr-xr-x 1 henson henson 1773576 May 21 12:54 back_bdb.so
(and no .la at all - on platforms where that's feasible)
The documentation currently says to use the .la file:
http://www.openldap.org/doc/admin24/slapdconf2.html#cn=module
Although under linux I've always just used the .so file myself. Getting rid of the .la would require a documentation update and also possibly config changes for everybody who listened to the documentation :).
Personally I use the .so file as well. The doc was written that way because the ".la" suffix exists on all platforms. Otherwise we'd have to write special cases for Windows and all the Unix variants.
Ryan Tandy wrote:
On Tue, May 22, 2018 at 12:51:49PM -0700, Paul B. Henson wrote:
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
Personally I'd even go further:
-rwxr-xr-x 1 henson henson 1773576 May 21 12:54 back_bdb.so
I'd say it's a mistake to remove the version info, since modules tend to be intimately tied to the specific version of OpenLDAP for which they were built.
Backends in particular are dependent on the specific slap.h. Password modules etc may be less version-dependent.
(and no .la at all - on platforms where that's feasible)
On Wed, May 23, 2018 at 07:48:09AM +0100, Howard Chu wrote:
I'd say it's a mistake to remove the version info, since modules tend to be intimately tied to the specific version of OpenLDAP for which they were built.
It's exactly that intimate coupling that makes me feel like the version info doesn't add much value. For myself I tend to consider modules as belonging to the specific slapd they were built with.
From: Howard Chu Sent: Tuesday, May 22, 2018 11:48 PM
-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
I'd say it's a mistake to remove the version info, since modules tend to be intimately tied to the specific version of OpenLDAP for which they were built.
Do you mean the "-2.4" as part of the filename, or the version in the extension " so.2.10.9"?
Wouldn't the server typically be installed alongside of the appropriate modules either via the package manager or a 'make install'? I guess you could get into a scenario where you have an orphaned module floating around, but given the config would just include "module.so" and not the versioned name, having a versioned name wouldn't keep it from failing?
openldap-technical@openldap.org
-
Howard Chu -
Paul B. Henson -
Quanah Gibson-Mount -
Robert Heller -
Ryan Tandy