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

[Ludovic Courtès]

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