From: ludo@gnu.org (Ludovic Courtès)
To: guile-devel@gnu.org
Subject: Extension search path changed in 1.9
Date: Tue, 23 Nov 2010 21:56:24 +0100 [thread overview]
Message-ID: <87d3pv3gjr.fsf@gnu.org> (raw)
Hello!
‘sysdep_dynl_init’ has been doing this for some time in 1.9:
--8<---------------cut here---------------start------------->8---
env = getenv ("GUILE_SYSTEM_EXTENSIONS_PATH");
[...]
if (env)
lt_dladdsearchdir (env);
else
{
lt_dladdsearchdir (SCM_LIB_DIR);
lt_dladdsearchdir (SCM_EXTENSIONS_DIR);
}
--8<---------------cut here---------------end--------------->8---
While these functions /append/ their argument to ltdl’s search path,
said path (‘user_search_path’ in ltdl.c) actually prevails over
$LTDL_LIBRARY_PATH and $LD_LIBRARY_PATH:
--8<---------------cut here---------------start------------->8---
static int
try_dlopen (lt_dlhandle *phandle, const char *filename, const char *ext,
lt_dladvise advise)
{
[...]
const char *search_path = user_search_path;
if (search_path)
file = find_file (user_search_path, base_name, &dir);
if (!file)
{
search_path = getenv (LTDL_SEARCHPATH_VAR);
if (search_path)
file = find_file (search_path, base_name, &dir);
}
[...]
}
--8<---------------cut here---------------end--------------->8---
(See
<http://git.savannah.gnu.org/cgit/libtool.git/tree/libltdl/ltdl.c#n1342>.)
This introduces a difference compared to 1.8.
In 1.8, to run the test suite of libguile-foo from its build tree, I
typically had a ‘pre-inst-guile’ like this:
--8<---------------cut here---------------start------------->8---
exec @abs_top_builddir@/libtool --mode=execute \
-dlopen "@abs_top_builddir@/src/libguile-foo.la" \
@GUILE@ "$@"
--8<---------------cut here---------------end--------------->8---
which amounts to “LD_LIBRARY_PATH=$PWD/src/.libs:$LD_LIBRARY_PATH” on
GNU/Linux.
However, this no longer works with 2.0: if libguile-foo.so is already
present in SCM_EXTENSIONS_DIR, then it will be loaded instead of the one
from the build tree.
In 2.0, the script above can be fixed by preceding the guile invocation
by:
--8<---------------cut here---------------start------------->8---
GUILE_SYSTEM_EXTENSIONS_PATH="@abs_top_builddir@/src"
export GUILE_SYSTEM_EXTENSIONS_PATH
--8<---------------cut here---------------end--------------->8---
I’m not sure what can be done. We could document
$GUILE_SYSTEM_EXTENSIONS_PATH.
I suspect it may hit other Guile users, so at least this message
documents the problem. :-)
Thanks,
Ludo’.
next reply other threads:[~2010-11-23 20:56 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-23 20:56 Ludovic Courtès [this message]
2011-02-11 15:33 ` Extension search path changed in 1.9 Andy Wingo
2011-02-11 16:01 ` Ludovic Courtès
2011-02-11 17:16 ` Andy Wingo
2011-02-12 10:13 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87d3pv3gjr.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=guile-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).