omitting SONAMEs for plugins?

[Michael Tokarev]

02.11.2022 18:37, Stefan Metzmacher via samba-technical wrote:
> Am 31.10.22 um 10:22 schrieb Michael Tokarev via samba-technical:
>> Hi!
>>
>> What's different between a shared library and a plugin is that
>> a plugin does not have a SONAME, while a library should have
>> one.
>>
>> When samba is built, SONAME is added to all shared objects, be
>> it a library or a plugin.
>>
>> I'm not familiar with waf (and with python) enough to understand
>> how the final link command is constructed, the thing is quite
>> a bit complicated there, with multiple layers and multiple
>> operating systems and linkers support.
>>
>> Is there a way to omit the SONAME field for plugins?
> 
> We have SAMBA_PLUGIN() instead of SAMBA_LIBRARY() and SAMBA_MODULE()

Yes, I've seen SAMBA_PLUGIN(). It is not used for stuff like /usr/lib/samba/vfs/*.so,
/usr/lib/samba/ldb/*.so, /usr/lib/samba/idmap/*.so and so on, which are
plugins. It's used for pam and nss stuff only.

But it is not what I asked. SAMBA_PLUGIN does provide SONAME at the link
time, for example here's how pam_winbind is being linked:

'/usr/lib/ccache/gcc', '-Wl,--as-needed', '-Wl,-h,pam_winbind.so', \
    '-shared',... '-o/<<PKGBUILDDIR>>/bin/default/nsswitch/lib_plugin_pamwinbind.inst.so'...

Note -Wl,-h,pam_winbind.so : this is the SONAME in the shared library.

What I asked was whenever it is possible to _omit_ this -Wl,-h for all
samba plugins.  So far I haven't found a way to omit this -Wl,-h for
certain dynamically linked objects.

Why.

Well, the thing is somewhat interesting.

Debian has a tool, dpkg-shlibdeps, which tries to find packages where
each referenced-by-an-executable symbol is located. For that it checks
for all UNDEFINED symbols in all libraries this executable is linked
with.

For many samba internal libraries it dumps quite a lot of warnings -
"symbol SYM used by libsamba-LIB.so found in none of its libraries".
For example:

  symbol find_domain_from_name used by \
    debian/winbind/usr/lib/x86_64-linux-gnu/samba/libidmap-samba4.so.0 \
    found in none of the libraries

This is actually a build system bug, a missing dependency information
between internal samba libraries.  I guess this can and should be
fixed, but keeping this info in wscripts up to date is rather
difficult (maybe some automatic tool can be used for this).  This is
not a problem in practice because all executables linked with that
library are *also* linked with their dependencies already, so at ld.so
is able to resolve all symbols. But it works just by a chance, because
it so *happens* all the executable loads all the required libraries
already.

But there are many plugns too. Which *might* have unresolved symbols,
which are provided by the executable which load them.  And it is
interesting whenever samba have such plugins to begin with, - I guess
most of them should *not* use any application-provided symbols, except
maybe the vfs modules (which are loaded by smbd only, hopefully anyway).

So it looks like my question is moot. A better question would be what
to do with such libraries which lack dependencies. There are many of
them.  Omitting some -Wl,-no-undefined reveals them nicely, but it
is, again, difficult to distinguish where this should be used and where
it shouldn't.

Why the plugin context popped up is because this same Debian tool,
dpkg-shlibdeps, omits these warnings for shared objects with no
SONAME field, which is the only sane way to distinguish a plugin
from a regular shared library.

Thanks!

/mjt