[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Preloading without .la
From: |
Ralf Wildenhues |
Subject: |
Re: Preloading without .la |
Date: |
Wed, 4 Jan 2006 18:02:17 +0100 |
User-agent: |
Mutt/1.5.11 |
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