Hi Peter, * Peter Breitenlohner wrote on Fri, Nov 18, 2005 at 03:27:06PM CET: > On Thu, 17 Nov 2005, Ralf Wildenhues wrote: > > >It might be even more useful to fix this bug! libltdl should not _need_ > >the .la file at all, neither the .a file. > > > >We have an entry for this on our online TODO list: > >http://tkd.kicks-ass.net/GnuLibtoolProject/RoadMap > > > >If you feel adventurous to work on a fix, be our guest! ;-) > > I might actually do that. > > If so, I would imagine this strategy for lt_dlopenext(filename): > > if FILENAME is nonempty and has no extension > > append ".a" (is it clear that this is right in all cases?)
Nope. Do not append .a, neither is it clear. First: Look if we preopened this one. > bypass try_dlopen() > > check for module already open and return as in tryall_dlopen() > > bypass all (system or user defined) loaders and directly try to > open the preloaded module via presym_open() > return if successful > > MAYBE: > if FILENAME has extension".la" change that to ".a" and try as above Well, the same thing has to work with the .la for lt_dlopen(). > Next try to append ".la" and proceed as in the existing version > > ================ > > All that could actually be implemented by giving the two static functions > try_dlopen() and tryall_dlopen() an additional argument PRELOADED, such that > they only try to load preloaded or non-preloaded modules. Probably. I haven't thought about this yet, though. One thing to consider is that we should not disallow users to choose names which are allowed now. This is important for CVS HEAD: there, all module loaders are themselves preloaded modules (e.g., there is a module for the LoadLibrary() interface, one for dlopen(), etc). > ================ > > Some questions: > > What about this idea? > > Would it be OK to produce a patch relative to the libtool-1.5.10 release? Actually, we much rather like patches against CVS HEAD. We can still backport to branch-1-5 then. Also, note CVS HEAD changed quite a bit in this area, so it's bound to be a bit more complex there. But still I'm very reluctant to take patches which aren't strictly bug fixes against branch-1-5 unless we also have a version for HEAD. > Should lt_dlopen("mod.la") behave as lt_dlopenext("mod")? I think so. > Shouldn't the "dlpreload" loader be removed from the chain of loaders (or > rather ignored in tryall_dlopen()) and treated as a special case (similar as > described above)? Well, I believe the author of the original code thought it could be done without special treatment.. > I have the impression that the "dlpreload" loader can only succeed with a > filename ending in ".a" (or the program itself), whereas all other loaders > will never succeed with such a filename. Is that correct? Well, there are more bugs in this area. The most prominent being the failure of preopening on systems with need_lib_prefix: http://lists.gnu.org/archive/html/libtool/2005-10/msg00045.html > Probably not true, since I remember that AIX has shared libraries named > "libFOO.a". On the other hand, in ltdl's configure I only found ".so", > ".dll", ".sl", and ".dylib". You should probably look at the other TODO issues as well, just so you know the terrain a bit, - fix ltdl for different library naming schemes * http://lists.gnu.org/archive/html/libtool/2005-08/msg00107.html * http://lists.gnu.org/archive/html/libtool/2005-09/msg00030.html * http://lists.gnu.org/archive/html/libtool/2005-09/msg00042.html - discuss naming scheme lib$name vs $name. * see e.g. https://sourceforge.net/forum/message.php?msg_id=3303527 * http://lists.gnu.org/archive/html/libtool/2005-08/msg00107.html - stress-test libltdl. Use every single exported interface, multiple time from multiple libraries, multithreaded. - fix AIX dlopen "self" I believe the last one could be fixed by dlpreopening the program. > But what about "libtool --mode=link -shrext SUFFIX"?? Gah! How should (an installed) libltdl know about an arbitrary suffix, unless it is given either in the argument or stored in a .la file? Sorry, I haven't thought about all this too much yet. Cheers, Ralf _______________________________________________ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool