[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libtool-1.5.20 -- lt_dlopenext fails to open preloaded module

From: Ralf Wildenhues
Subject: Re: libtool-1.5.20 -- lt_dlopenext fails to open preloaded module
Date: Sun, 20 Nov 2005 09:01:21 +0100
User-agent: Mutt/1.5.9i

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
>       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:

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]