Re: libltdl obscures error messages

[Marius Vollmer]

Gary V.Vaughan <address@hidden> writes:

> On Tuesday 24 July 2001 9:51 pm, Marius Vollmer wrote:
> > Hi,
> 
> `Tag Marius,

Moin!
 
> > The fix would be to distinguish between "file not found" errors (which
> > can be repaired by trying the next candidate), and other errors (which
> > should be immediately passed to the caller).
> 
> That sounds like a good plan to me.
>
> [...] We would be extremely grateful for any help you would like to
> offer...

Hmm, well, I can see two approaches: the first is to redefine the
search algorithm of libltdl so that tryall_dlopen will only be called
with absolute filenames.  This way, we would first search for a file,
using the various search paths and suffices (in the case of
lt_dlopenext), and only when we have found an existing file, we would
call tryall_dlopen, once.

The other approach is to extend the internal error reporting of
tryall_dlopen and (an internal version of) lt_dlopen to reliably flag
file-not-found errors, and react to them appropriately.  This way, we
would still have the platform native searching behavior of the native
dlopen machinery, but we need a way to reliably learn from dlopen,
say, that it has failed due to a file-not-found condition.

I think the second approach is preferable if we can make it work.  It
is good to offer the native searching behavior since it is hard to
simulate reliably.

My man page about dlopen does not mention ENOENT or other relible ways
to tell that it failed due to file-not-found, although some
experiments seem to indicate that dlopen does indeed set errno to
ENOENT.  Whether that's only by accident, I don't know.

What about the other backends?