Re: libltdl obscures error messages

[Marius Vollmer]

Gary V.Vaughan <address@hidden> writes:

> `Tag Marius,
> 
> On Saturday 28 July 2001 11:02 am, Marius Vollmer wrote:
>
> > Sorry, wrong wording.  With "fix", I meant that dlopen should `fix'
> > its current behavior of setting errno, so that we can be sure that
> > this bevaior doesn't disappear in the future.  Even if it only sets
> > errno accidentally in the existing versions, we can rely on it, since
> > it is not going to change.
> 
> Do you mean that lt_dlopen should set ENOENT when it detects that the load 
> failed due to "No such file"?

No, I was talking about the system's dlopen function (as an example
for a backend), not about lt_dlopen.

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

> Having thought about this some more, I am beginning to wonder
> whether correct error message propogation within libltdl even needs
> to rely on system level file not found reporting at all?  I think we
> should be able to hold on to the most recent system error message,
> and if (after tryall_dlopen) libltdl's internal reporting has only a
> FILE_NOT_FOUND passes back the system error instead...

I'm not sure I understand.  For filenames constructed while searching
the libltdl search paths (like LTDL_LIBRARY_PATH), we can check for
the existence of the files ourselves (via access or open), but for the
`native' searching done by tryall_dlopen, we can't know why it failed
without cooperation from the native backend.  We need to know why it
failed so that we can decide whether to use the next extension or not.

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.

> > [ Testing your German, eh? ;-) ]
> 
> [With the aid of a dictionary:] Ich pflegte, im Afrikaans und nicht
> zum schlechten am Deutschen fliessend zu sein. Heutzutage ist mein
> Japaner besser als beide.

Spitze!  Ich kann nur ein bischen Englisch...