Re: Preloading without .la

[Ralf Wildenhues]

Hi Pierre,

* Pierre Ossman wrote on Tue, Jan 03, 2006 at 05:36:05PM CET:
> I've been trying to use ltdl preloading without having any .la files, 
> something that doesn't currently seem to be supported. I'm willing to 
> implement a fix, provided a way out is presented.
> 
> The problem is that preloaded modules are given their static lib name, 
> "foo.a". When loading the module, ltdl searches for "foo.so" and 
> "foo.la". If "foo.la" exists, then "foo.a" will be found since that is 
> the name in the "old_library" field of the la-file.

> Comments welcome.

Yes, two comments.  First, read this thread as well:
http://lists.gnu.org/archive/html/bug-libtool/2005-11/msg00000.html

Second, think about systems with need_lib_prefix as well -- I believe
the fix to both issues should be very similar.  Documented here:
http://lists.gnu.org/archive/html/libtool/2005-10/msg00045.html

Third, if you could write a test for CVS libtool as well, that would
be *great*.

> I see two possible solutions to get things working smoothly:
> 
>  * Add the suffix of static libs to the ones searched for by libltdl.
>    Currently this includes ".la" and that of shared objects.
>    Since this is platform and/or compiler specific it might be a pain
>    to get working everywhere. It's still solvable by doing it as we
>    encounter the problems.

You could AC_DEFINE it from libtool.m4 ($libext).

>  * Use the dynamic prefix for the name embedded in the preload module.
>    I.e. do a 'sed s/$(STATIC_EXT)\$/$(SHLIB_EXT)/' on the name as it is
>    being embedded. Not sure what the obstacles are here. Perhaps some
>    problem with breaking existing hacks.

Hmm, maybe.  I'm not sure yet about the best solution.  Adding (or
removing?) the `lib' prefix (which also may be spelled differently!)
may be needed as well, see above.

This approach has the disadvantage of breaking ABI on preloaded module
files -- not sure if we should care very much, but enough to make me
not want to put this in branch-1-5 probably.  Dunno yet, need to see
a working version and test it first.

* Pierre Ossman wrote on Wed, Jan 04, 2006 at 10:55:29AM CET:
> >
> >And this would be the patch in the second case.

> For HEAD there is already a mangling where func_basename is used

Yes.

> (which I assume removes the suffix aswell).

No.  It should be functionally equivalent to the 1.5.x version.

> Should programs using ltdl 2.0 call both lt_dlopen and lt_dlopenext to
> cover both preloaded and on-disk modules?

No, I don't think so.

Your patch has a few issues.  First, `$shrext_cmds' is not necessarily a
literal, but may contain commands; `$std_shrext' may be used instead.
Second, the change breaks libltdl for both branch-1-5 and HEAD, but in
slightly different ways: in both you will be able to load the module
with the .so name, but not any more with the .la name.  Additionally,
branch-1-5 will not find the symbols any more.  You can test this with
libtool's mdemo test.

I'm sorry I haven't had time yet to look into a better fix.

Cheers,
Ralf

> --- ltmain.in 18 Dec 2005 21:52:53 -0000      1.334.2.115
> +++ ltmain.in 4 Jan 2006 09:49:05 -0000
> @@ -4570,7 +4570,7 @@
>  
>         for arg in $dlprefiles; do
>           $show "extracting global C symbols from \`$arg'"
> -         name=`$echo "$arg" | ${SED} -e 's%^.*/%%'`
> +         name=`$echo "$arg" | ${SED} -e 's%^.*/%%' | ${SED} -e 
> 's%[.][^.]*$%%'`$shrext_cmds
>           $run eval '$echo ": $name " >> "$nlist"'
>           $run eval "$NM $arg | $global_symbol_pipe >> '$nlist'"
>         done