Subject: bug#21076: closed (Re: bug#21076: dynamic-link often fails to load libraries)

From: [email-masked] (GNU bug Tracking System)
Date: Sat, 21 Mar 2020 23:27:02 +0000

Your bug report

#21076: dynamic-link often fails to load libraries

which was filed against the guile package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
21076: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21076
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#21076: dynamic-link often fails to load libraries
From: Ludovic Courtès <[email-masked]>
To: Isaac Jurado <[email-masked]>
Cc: [email-masked], Matt Wette <[email-masked]>
Date: Sun, 22 Mar 2020 00:26:44 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

Hi Isaac,

Isaac Jurado <[email-masked]> skribis:

> From b337d412b3c10cabe355df07d2295c4d0a560b10 Mon Sep 17 00:00:00 2001
> From: Isaac Jurado <[email-masked]>
> Date: Sat, 8 Jun 2019 14:00:29 +0200
> Subject: [PATCH] Interpret dynamic library name as literal path first.
>
> Fixes <https://bugs.gnu.org/21076>.
>
> * libguile/dynl.c (sysdep_dyn_link): Try plain lt_dlopen first, to
>   interpret fname as a literal path.
> * doc/ref/api-foreign.texi: Update explanation to describe the new
>   behavior.

It’s taken a while (!), but thanks to Matt Wette’s ping, it’s now
applied on ‘master’ and will make it into 3.0.2.

I slightly modified the documentation wording as shown in the patch
below (the GNU convention is to use “file name” for file names and
“path” for search paths).

Like you wrote, it’s hard to test, but I think it’s OK to leave it as is.

Thanks!

Ludo’.

diff --git a/doc/ref/api-foreign.texi b/doc/ref/api-foreign.texi
index 94fabf23c..b0d6c249b 100644
--- a/doc/ref/api-foreign.texi
+++ b/doc/ref/api-foreign.texi
@@ -75,14 +75,14 @@ Scheme object suitable for representing the linked object file.
 Otherwise an error is thrown.  How object files are searched is system
 dependent.
 
-Guile first tries to load @var{library} as a full path to a shared
-library file.  If that fails, then it falls back to interpret
+Guile first tries to load @var{library} as the absolute file name of a shared
+library.  If that fails, it then falls back to interpret
 @var{library} as just the name of some shared library that will be
 searched for in the places where shared libraries usually reside, such
 as @file{/usr/lib} and @file{/usr/local/lib}.
 
 @var{library} should not contain an extension such as @code{.so}, unless
-@var{library} represents the full path to the shared library file.  The
+@var{library} represents the absolute file name to the shared library.  The
 correct file name extension for the host operating system is provided
 automatically, according to libltdl's rules (@pxref{Libltdl interface,
 lt_dlopenext, @code{lt_dlopenext}, libtool, Shared Library Support for

Subject: dynamic-link often fails to load libraries
From: Frank Webster <[email-masked]>
To: [email-masked]
Date: Thu, 16 Jul 2015 19:52:34 +0300
List-Id: <debbugs-submit.debbugs.gnu.org>

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.

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.

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.

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.

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.