Adrian Bunk <bunk@xxxxxxxxx> writes:
> > > > > LDFLAGS="-L/usr/local/lib -R/usr/local/lib" ../configure
> > > > > didn't work
> > > >
> > > > Why didn't this work? Does the sparc-netbsdelf1.5 linker support the
> > > > -R option? If it does not support -R, does it support --rpath? Was
> > >
> > > -R is not an option for ld, it's an option for gcc.
> >
> > That turns out not to be the case. Insofar as gcc supports the -R
> > option, it supports it by passing it on to the linker.
> >
> > In fact, the gcc documentation does not even document -R. The GNU
> > linker documentation does document -R.
> >
> > On my i386 GNU/Linux system (Fedora Core 1) I get this:
> >
> > gossamer> gcc -R/tmp -o hello hello.o
> > gcc: unrecognized option `-R/tmp'
> > gossamer> gcc -Wl,-R/tmp -o hello hello.o
> > gossamer> objdump -p hello | grep RPATH
> > RPATH /tmp
>
> Yes, you are on Linux.
>
> On NetBSD, it's available (see gcc/config/netbsd-elf.h).
True. And note, in that file, how gcc implements -R by simply passing
it directly to the linker.
> > > > the -R option actually used when linking gcc?
> > >
> > > Obviously were the LDFLAGS not used...
> >
> > The obvious case is that things work correctly. When things fail to
> > work, you must look at what actually happened, not at what is obvious.
> >
> > It might possibly be worth trying
> > LDFLAGS="-Wl,-R/usr/local/lib" ../configure
> > Hard to say.
>
> This wouldn't make any difference:
> - the -R option works fine on my platform
Good to hear. That answers my initial question.
> - if LDFLAGS were used and -R wouldn't work, I should have gotten an
> error while bootstrapping gcc
That is not necessarily the case, as when the gcc driver sees an
unrecognized option, it will issue a warning but will still exit with
a successful status (I think this is a bug and in fact I just filed a
PR about it, but it is true nonetheless).
Have you tried
make LDFLAGS="-L/usr/local/lib -R/usr/local/lib"
?
Ian
