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

[Daniel Jacobowitz <drow@mvista.com>]

On Tue, Nov 27, 2001 at 07:25:55PM +0100, Orjan Friberg wrote:
> Daniel Jacobowitz wrote:
> > 
> > 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.
> 
> I'm sorry; I still fail to see your point.  Let me try and break my
> thinking down, and I'd be grateful if you could point out where I'm
> wrong.  To me it seems the question is whether openp should ever be fed
> an absolute path in solib_open.
> 
> Using your example, if it's opened as "/lib/mmx/libc.so.6" it's an
> absolute path, so it will be handled by the following code:

Right.

> It will try and open the absolute path, prefixed by
> solib_absolute_prefix if it has been set.

Right.

> Otherwise, it will try the following:
> 
>   /* If not found, next search the solib_search_path (if any).  */
>   if (found_file < 0 && solib_search_path != NULL)
>     found_file = openp (solib_search_path,
> 			1, in_pathname, O_RDONLY, 0, &temp_pathname);

Also right, of course.

> If /lib/mmx/libc.so.6 was opened with a relative path, then
> solib_search_path would have to be set correctly for us to find it, no? 
> What I fail to see is why we'd want openp to open an absolute path, when
> we know we want to look in solib_search_path.

We don't know that!

Suppose that I dlopen ("/lib/mmx/libc.so.6", ...).  That's the case I
am describing.  The only way to handle this case properly (assuming
there is also a /lib/libc.so.6) is to go through one of the absolute
path cases.  There is no other option.

> > 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.
> 
> I do see your point; falling back on searching on the basename only will
> certainly get me in trouble if there are several solibs with the same
> name.  I also realized just now that an application's solibs won't be in
> the same directory on my host as the ones installed with the compiler,
> so I'm definitely in trouble (unless we would allow multiple solib
> search paths.)  Looks like I have to take the mirrored target filesystem
> route after all.  (That doesn't affect the absolute path vs openp
> question though.)

solib-search-path is colon separated; why is this a problem?

My point still holds, though.

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