Re: new shlibpath_overrides_runpath test

[Ralf Wildenhues]

Hello Peter,

* Peter O'Gorman wrote on Sun, Sep 17, 2006 at 01:23:18AM CEST:
> On Sep 17, 2006, at 1:11 AM, Ralf Wildenhues wrote:
> >* Peter O'Gorman wrote on Sat, Sep 16, 2006 at 06:07:33PM CEST:
> >>On Sep 16, 2006, at 7:12 AM, Ralf Wildenhues wrote:
> >>
> >>>+$CC $CPPFLAGS $CFLAGS -c m.c
> >>>+AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o m m.$OBJEXT
> >>>-Lsub/lib -la -R`pwd`/sub/lib],
> >>
> >>I'm probably just being dumb, but what is that -R doing there?
> >
> >Well, I removed the file sub/lib/liba.la before this link line, so
> >libtool won't hardcode the path for us without the -R.
> >
> >It's not the only case that is interesting, sure, but it is definitely
> >one we should also care about.
> 
> Okay, then the test ought to be limited to systems which accept the - 
> R flag, shouldn't it?

Erm, on which systems does `libtool --mode=link' not accept -R?
Note that libtool may translate the -R flag that it gets into different
things depending on the host system.  All systems that allow any kind of
directory hardcode mechanism should get treated in some way this way.

The reason I wrote the test this way is that I wanted to prevent the
actual library of being hardcoded this way, say, by an absolute
DT_NEEDED entry (as is possible on OpenBSD, for example).  This would
prevent us from overriding DT_RPATH by $shlibpath_var, even if otherwise
it would override.

I'll happily add other cases to the test (including the ones tested
by demo-relink and depdemo-relink, after I've looked at them in more
detail) if you suggest so; in case of inconsistencies, we may have
to introduce another libtool variable.  My point was though that in
case of any doubt, shlibpath_overrides_runpath should be set to yes:
adding to the $shlibpath_var most rarely hurts the execution of an
uninstalled program.

The consequence of this thought was that I should use the weakest
test possible (i.e., one hardcoding the directory is preferable over
one hardcoding an actual absolute library name), and if that can be
overridden, we should do it.

(Note the test of "$shlibpath_overrides_runpath" != no is due to some
systems having it set to unknown, including AIX (where the situation is
again a bit more complex); hmm, I still have to look up why that is not
used in ltmain.m4sh as well...)

Cheers,
Ralf