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

[Isaac Jurado <diptongo@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 473 bytes --]

I've experienced this issue as well, but the fix is very simple
(attaching Git patch).

The fix does NOT break foreign.test but I have no idea, yet, on how to
test the new behaviour in a platform independent or continuous
integration friendly way.

The commit has been applied to the stable-2.2 branch, but it would
also apply cleanly to master.

Any feedback welcomed.

Best regards.

-- 
Isaac Jurado

"The noblest pleasure is the joy of understanding"
Leonardo da Vinci

[-- Attachment #2: 0001-Interpret-dynamic-library-name-as-literal-path-first.patch --]
[-- Type: text/x-patch, Size: 2402 bytes --]

From b337d412b3c10cabe355df07d2295c4d0a560b10 Mon Sep 17 00:00:00 2001
From: Isaac Jurado <diptongo@gmail.com>
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.
---
 doc/ref/api-foreign.texi | 13 ++++++++-----
 libguile/dynl.c          |  7 +++----
 2 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/doc/ref/api-foreign.texi b/doc/ref/api-foreign.texi
index d99a33300..94fabf23c 100644
--- a/doc/ref/api-foreign.texi
+++ b/doc/ref/api-foreign.texi
@@ -75,11 +75,14 @@ Scheme object suitable for representing the linked object file.
 Otherwise an error is thrown.  How object files are searched is system
 dependent.
 
-Normally, @var{library} is just the name of some shared library file
-that will be searched for in the places where shared libraries usually
-reside, such as in @file{/usr/lib} and @file{/usr/local/lib}.
-
-@var{library} should not contain an extension such as @code{.so}.  The
+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
+@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
 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
diff --git a/libguile/dynl.c b/libguile/dynl.c
index 2a25e5d2e..0096e8cf5 100644
--- a/libguile/dynl.c
+++ b/libguile/dynl.c
@@ -79,10 +79,9 @@ sysdep_dynl_link (const char *fname, const char *subr)
 {
   lt_dlhandle handle;
 
-  if (fname == NULL)
-    /* Return a handle for the program as a whole.  */
-    handle = lt_dlopen (NULL);
-  else
+  /* Try the literal filename first or, if NULL, the program itself */
+  handle = lt_dlopen (fname);
+  if (handle == NULL)
     {
       handle = lt_dlopenext (fname);
 
-- 
2.17.1