--- Begin Message ---
|
Subject: |
dynamic-link often fails to load libraries |
|
Date: |
Thu, 16 Jul 2015 19:52:34 +0300 |
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.
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#21076: dynamic-link often fails to load libraries |
|
Date: |
Sun, 22 Mar 2020 00:26:44 +0100 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) |
Hi Isaac,
Isaac Jurado <address@hidden> skribis:
> From b337d412b3c10cabe355df07d2295c4d0a560b10 Mon Sep 17 00:00:00 2001
> From: Isaac Jurado <address@hidden>
> 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
--- End Message ---