Re: new shlibpath_overrides_runpath test

[Peter O'Gorman]

On Sep 17, 2006, at 7:12 PM, Ralf Wildenhues wrote:

> 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.

And on systems that do not, the -R flag seems to be dropped entirely  
from the link line. I have never actually used -R with libtool  
myself, so was not aware of it,  I was being stupid, sorry.

The patch is okay, both parts, now that I understand where you're  
going :)

Peter