bug#21076: dynamic-link often fails to load libraries

[Andreas Rottmann]

Frank Webster <address@hidden> writes:

> On my Debian system, `dynamic-link' often fails to load shared
> libraries:
>
> Loading using a versioned soname never works:
>
> scheme@(guile-user)> (dynamic-link "libGL.so.1")
> ERROR: In procedure dynamic-link:
> ERROR: In procedure dynamic-link: file: "libGL.so.1", message: "file not 
> found"
>
> Loading without a library extension doesn't work unless the
> corresponding *-dev package is installed:
>
> scheme@(guile-user)> (dynamic-link "libGL")
> ERROR: In procedure dynamic-link:
> ERROR: In procedure dynamic-link: file: "libGL", message: "file not found"
>
> It is supposed to work with or without the extension, however because
> of limitations in the underlying lt_dlopenext function in libtool,
> neither works.
>
I'd argue that using the second variant (or using `(dynamic-link
"libGL.so")') is kinda inherently broken in an application loading
general-use (public) shared libraries, as opposed to plugins specific to
an application: you have no idea what ABI the library you just loaded
has. This means you may later use of symbols from that library in a way
that violates the ABI.

Unfortunatly, how the ABI is encoded into the shared library name is
platform-dependent, and this is also (as I read between the lines of the
bug thread referenced by you [0]) one of the reasons why the libtool
developers are not sure how a solution to this problem should look
like.

I think to write an application that is somewhat protected against ABI
changes, you need to have a mapping from ABIs supported by your
application to shared library file names (including the version
extension). You might have only one supported ABI, but the mapping is
still platform-dependent, so you have to either have a run-time or
build/install-time switch choosing the appriopriate shared library name.

Now, to make matters worse, you can't do that using libltdl, as you
noticed:

> The first doesn't work because contrary to its
> documentation, lt_dlopenext doesn't always try loading
> the bare filename first, without appending an extention.
>
Yes, this is a really annoying bug, and is what kept me from (trying to)
port sbank[1] (a gobject-introspection binding) to Guile a few years
back. In gobject-introspection, you get the full shared library file
name, along with a machine-readable ABI description, but you can't open
the shared library using the versioned name in Guile.

[1] https://github.com/rotty/sbank

> The second doesn't work because the versioned soname extension (.so.1)
> isn't among the ones that lt_dlopenext tries to append. It does try the
> unversioned extension (.so), but in Debian the unversioned symlink
> is only available when the corresponding *-dev package is installed.
>
Yeah, but IMHO, this kind of use with a bare shared library name
(without SONAME/ABI information) is already misguided in the first
place, unless you have some other way of knowing the ABI. Debian and the
likes not installing .so files (or .la files) by default only exposes
the inherent potential breakage.

[0]
> Here is a related libtool bug report: https://debbugs.gnu.org/8976
>
> Note that there are arguably two distinct issues:
> (1) lt_dlopenext not trying the bare filename in all cases
> (2) lt_dlopenext not trying versioned soname extensions.
>
> Obviously one way to address this would be to fix these two issues in
> lt_dlopenext in libtool.
>
As mentioned, solving problem (2) is not a good idea IMO -- the versions
are there for a reason, and you cannot (should not) guess them.

> Alternatively, the (system foreign) module in guile could provide a
> simple low-level wrapper around lt_dlopen, and possibly implement
> the higher level functionality of `dynamic-link' (additional search
> paths, guessing extensions etc.) in scheme.
>
+1

Regards, Rotty
-- 
Andreas Rottmann -- <http://rotty.xx.vu/>