Add a way to configure the build to embed plugins into the main libsasl2.so like --with-staticsasl does with libsasl.a

[Romain-Geissler-1A]

Hi,

We are hitting a small issue with libsasl2 as it comes with a plugin mechanism which is a bit incompatible with how we build/deliver/deploy software. Usually we expect a lib to be kind like a "normal" library: either autonomous, either depending on other "normal" libraries and having the expected ELF DT_NEEDED dependencies (or whatever equivalent at build system level to describe a dependency). Libraries coming with the concept of plugins like libsasl2, which "auto-discovers" at runtime which plugins are available by opening a built-time hardcoded default plugin folder aren't ideal, as the dependencies are more runtime one, and don't really accept libraries to be just in LD_LIBRARY_PATH like other "normal" libraries.

All the other open source libraries we use and which have a similar plugin concept (for example OpenSSL with dynamic engine loading, or the mariadb c-connector with different authentication mechanism) all have a build-time option to actually embed the .o files of the plugins directly into the final lib .a or .so file. I didn't find such a way to configure libsasl2. Would it make sense to add such an option (of course, disable by default to keep the existing behavior) ? This way libsasl2.so would be a "normal" library, potentially depending on things like kerberos runtime libraries, without addition plugin runtime dependencies.

EDIT:

After the first reply/closure from @hyc, I am reopening this ticket with a different title and here with an updated request. Basically I wonder if we could offer a way to configure libsasl at build time so that in the shared library libsasl2.so we could embed all the plugins inside the .so (rather than having external plugin .so which are dlopened at runtime), like what --with-staticsasl does (but --with-staticsasl seems to do it ONLY for the static library libsasl.a).

Thanks

[hyc]

That's what --with-staticsasl does.

[Romain-Geissler-1A]

I just tried --with-staticsasl (and looked at what it does really) and IMO it just enables both static and dynamic library, and for the static lib it indeed embeds the mechanism inside the lib, but for the the dynamic library these are still external plugins. So it is half way what I would like to have. Would it be possible to have an .so file with the same content as the .a file when configured with --with-staticsasl ?

[Romain-Geissler-1A]

Hi @hyc,

I have changed a bit the title of this request and added an EDIT section in my request following your reply. Is this request valid with the re-phrased requirements ?

[Romain-Geissler-1A]

Ping @hyc