Re: Error reporting should be improved

[Ralf Wildenhues]

Hello everyone,

* Peter Rosin wrote on Tue, Dec 29, 2009 at 10:00:43PM CET:
> Den 2009-12-27 09:13 skrev Xiaoqiang Zhou:
> >I was using libtool to load a library which has unsatisfied
> 
> What version of libtool? On what system?

This hasn't been answered BTW.  But the problem exists in git master,
see the 'lt_dlopen error messages' test.

> >dependencies. libtool tells me that "file not found" while dlopen
> >gives the correct message "undefined symbol".
> >
> >This is because the last error was overridden by the subsequent
> >tries. Maybe we should stop trying once the right file was found.
> >This way the right message could be given to user.
> 
> The trouble is that it is not dlopen that gives this message, it is
> dlerror that gives the message, and it would be terrible to use
> string comparison to dig out the cause of the failure. And that's
> just for the dlopen loader, who knows how the other loaders behave
> on obscure systems in wierd corner cases. Finding a reliable way
> to catch all errors that are not "file not found" or equivalent
> and quit early will not be an easy task.
> 
> The loaders typically just report CANNOT_OPEN when something fails,
> and the ltdl core has no reliable way of knowing the underlying
> cause.
> 
> At least, that's my take on the situation...

There used to be code in tryall_dlopen using access() to try and guess
whether the module file is not available.  It has been commented out,
IIRC for good reason, and re-enabling it does not fix the aforementioned
test for me; but it might be possible to hack something similar (at the
right place) at least for absolute file names.

Yes, this is not a real and complete fix for the situation, and it
relies on libltdl knowing the correct dlsearch path.

I do like the idea that an error message from a non-preopen loader
has higher precedence over an error message from the preopen loader,
maybe that idea should be pursued first.

Thanks,
Ralf