Re: [RFC]: Solib search (Was: Re: Cross solib support; continued)

[Daniel Jacobowitz <drow@mvista.com>]

On Tue, Nov 27, 2001 at 04:36:08PM +0100, Orjan Friberg wrote:
> Daniel Jacobowitz wrote:
> > 
> > On Tue, Nov 27, 2001 at 04:03:45PM +0100, Orjan Friberg wrote:
> > >
> > > My thought was to make the path relative if the search for the absolute path failed,
> > > by simply getting rid of the leading '/'.  (It won't work with DOS based file
> > > systems, as the dir separator could be '\\', but that would be easy to add.)
> > > Needless to say, this works for me, but I'm not sure it's The Right Thing to do.
> > > (Another approach would be to change openp, but I'm sure there's a good reason for
> > > its current behaviour.)
> > 
> > I've got one concern with this.  In native debugging, we want to open
> > the absolute path BEFORE searching solib-search-path - you might have
> > dlopened() a specific optimized version of a library whose base exists
> > in /usr/lib, for instance.
> 
> I'm not sure I follow: wouldn't that be covered by solib_absolute_prefix being set to
> /usr/lib?  I mean, I haven't changed the order between searching in
> solib_absolute_prefix and solib_search_path.  Or do you mean the case where
> solib_absolute_prefix isn't set, and we end up searching for it using
> LD_LIBRARY_PATH?  Hm, maybe we should only make the path relative if we are about to
> search for the solib in solib_search_path, leaving the other cases unaffected.

That sounds a little better.  If there's a /lib/lib or a
/usr/lib/usr/lib it's their own fault.  I'm still not convinced,
though.

Consider if we dlopen "/lib/mmx/libc.so.6".  (We never do, the dynamic
linker takes care of that for this particular case.  But for ATLAS it's
another story.)

We won't find it in solib-search-path.  We won't find it if the path is
relative.  We will only find it if we hand that entire path to openp. 
We need to not disturb that.

Now consider the same thing in a cross environment.  This is why I very
strongly advocated mirroring the target filesystem.  There is no other
way to figure out which, if any, libc.so.6 this is.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer