Extension search path changed in 1.9

Extension search path changed in 1.9

[Ludovic Courtès]

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’.

Re: Extension search path changed in 1.9

[Andy Wingo]

Hi Ludovic,

On Tue 23 Nov 2010 21:56, ludo@gnu.org (Ludovic Courtès) writes:

> In 1.8, to run the test suite of libguile-foo from its build tree, I
> typically had a ‘pre-inst-guile’ like this:
>
> exec @abs_top_builddir@/libtool --mode=execute			\
>        -dlopen "@abs_top_builddir@/src/libguile-foo.la"	\
>        @GUILE@ "$@"
>
> 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.

This sounds like a bad change.  Should we append to the
LTDL_LIBRARY_PATH environment variable instead?  I guess that's what we
need to do with the libtools that are "out there".

WDYT?

Andy
-- 
http://wingolog.org/

Re: Extension search path changed in 1.9

[Ludovic Courtès]

Hi Andy,

Andy Wingo <wingo@pobox.com> writes:

> On Tue 23 Nov 2010 21:56, ludo@gnu.org (Ludovic Courtès) writes:
>
>> In 1.8, to run the test suite of libguile-foo from its build tree, I
>> typically had a ‘pre-inst-guile’ like this:
>>
>> exec @abs_top_builddir@/libtool --mode=execute			\
>>        -dlopen "@abs_top_builddir@/src/libguile-foo.la"	\
>>        @GUILE@ "$@"
>>
>> 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.
>
> This sounds like a bad change.  Should we append to the
> LTDL_LIBRARY_PATH environment variable instead?

Yes, let’s do that.  Sounds hackish but it would work.

> I guess that's what we need to do with the libtools that are "out
> there".

The libtool invocations you mean?

Thanks,
Ludo’.

Re: Extension search path changed in 1.9

[Andy Wingo]

On Fri 11 Feb 2011 17:01, ludo@gnu.org (Ludovic Courtès) writes:

>> I guess that's what we need to do with the libtools that are "out
>> there".
>
> The libtool invocations you mean?

No, the libltdls.  I was thinking about getting some other API into
ltdl, instead of hacking at environment variables; but hacks should be
sufficient for now I guess.

Cheers,

Andy
-- 
http://wingolog.org/

Re: Extension search path changed in 1.9

[Ludovic Courtès]

Andy Wingo <wingo@pobox.com> writes:

> On Fri 11 Feb 2011 17:01, ludo@gnu.org (Ludovic Courtès) writes:
>
>>> I guess that's what we need to do with the libtools that are "out
>>> there".
>>
>> The libtool invocations you mean?
>
> No, the libltdls.  I was thinking about getting some other API into
> ltdl, instead of hacking at environment variables; but hacks should be
> sufficient for now I guess.

Agreed.

Ludo'.