Re: lt_dlerror changes

[Peter O'Gorman]

On 06/17/2010 10:35 PM, Peter O'Gorman wrote:
> On 06/17/2010 10:21 PM, Charles Wilson wrote:
> > On 6/17/2010 10:24 PM, Peter O'Gorman wrote:
> > > > Unfortunately, this doesn't magically assist solving my problem with
> > > > 71. dlloader-api.at:23: FAILED (dlloader-api.at:422)
> > > > but that's not a reason to object to the patch.
> > >
> > >
> > > Well that sucks :(
> > >
> > > I suggest changing the LT__SETERROR macro in
> > > libltdl/libltdl/lt__private.h to print __FILE__ and __LINE__ etc. if
> > > errorcode == FILE_NOT_FOUND, then running test 71 again. It doesn't look
> > > like it's happening in loadlibrary.c.
> >
> > ../libtool/libltdl/loaders/preopen.c (188)
> > ../libtool/libltdl/loaders/preopen.c (188)
> > ../libtool/libltdl/loaders/preopen.c (188)
> >
> > Hmm. Adding more debug output to preopen.c:vm_open ...
> >
> > Searching for preloaded symbol table for dlopen.a
> >
> >
> > Err...why is it looking for a module named "/usr/bin/last"? Is it
> > somehow using a $PATH search, and matching "last" to
> > "/usr/bin/last.exe"? cygwin's dlopen does do some funky things with
> > $PATH, because that's how windows looks for DLLs -- but we're in
> > preopen, here...

Ok, it's adding a loader (at the end of the list of loaders), then 
trying to lt_dlopen("last"), that's going to try all other loaders 
before getting to the added loader, and in your case the loadlibrary 
loader finds /usr/bin/last (because /usr/bin is properly in the search 
path).

My changes to lt_dlerror should have given you the error from 
loadlibrary.c, but didn't, I will check why, it looks like the patch 
needs more work though.

Peter