libtool
[Top][All Lists]
Advanced

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

Re: libltdl obscures error messages


From: Gary V . Vaughan
Subject: Re: libltdl obscures error messages
Date: Tue, 31 Jul 2001 01:38:44 +0100

On Monday 30 July 2001 11:21 pm, Marius Vollmer wrote:
> Gary V.Vaughan <address@hidden> writes:
> > If you really do mean that dlopen should set ENOENT, libtool has no
> > control over that, and even if it is already common for architectures to
> > do so, I would be very surprised if it is done consistently for the huge
> > number of dlopen implementations out there, let alone the other dynamic
> > loading APIs that libltdl supports.  Therefore, this doesn't help
> > lt_dlopen to reliably detect failure to open a module due to "No such
> > file" conditions either.
>
> Yes, but what can we do?  If we know that dlopen does indeed set errno
> reliably (if not by design, then by implementation), and we can
> convince the implementors (i.e. the GNU libc guys) not to change this
> behavior (by getting them to document it), we can use it.  Similar
> approaches might work with the other backends, if they have the same
> problem.
>
> So the main question (for me) is: is it worthwhile to try to squeeze a
> reliable indication of a file-not-found condition out of the backends,
> or is there no hope that it will work out?  We don't need to get this
> indication from all backends immediatly, the ones who can not provide
> it will work as they do now, suboptimally.

Aha!  I'm with you now.  Yes, I agree that this approach is better than what 
we have now... the key is to not expect a decent response from the backends.  
If we can nail down a repeatable file-not-found condition for any of the 
backends, then that is a bonus, and we should indeed take advantage of that 
information to provide the client with better error reporting.

> Or, and I'm just now thought about this, we can redefine what it means
> to try a number of extensions, like so:
>
>     For every platform there is a "system extension" (LTDL_SHLIB_EXT).
>
>     If the filename handed to lt_dlopenext ends with ".la", we try a
>     libtool archive search and nothing else.
>
>     If the filename ends with the system extension, we try that and
>     nothing else.
>
>     If none of the above two cases applies, we try a ".la" search
>     (which we control completely, thus no problems with error
>     reporting) and if that failed because of a top-level
>     file-not-found error, we try a search with the system extension.
>
> Now, the problematic call to tryall_dlopen that is expected to perform
> the native searching is always the last thing we do, and we don't need
> its error reporting to decide whether to carry on or not.
>
> Hmm, I kinda like this approach.

Excellent.  I think this is what I was trying to express, only you have 
understood the problem and described the solution more precisely than I had 
yet cogniscised (is that a word?).  I would be delighted to help you 
implement this...  Watch out that I am about to commit a large patch that 
touches most of ltdl.c before you start hacking though =)O|

Cheers,
        Gary.
-- 
  ())_. Gary V. Vaughan     gary@(oranda.demon.co.uk|gnu.org)
  ( '/  Research Scientist  http://www.oranda.demon.co.uk       ,_())____
  / )=  GNU Hacker          http://www.gnu.org/software/libtool  \'      `&
`(_~)_  Tech' Author        http://sources.redhat.com/autobook   =`---d__/



reply via email to

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