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 _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
