Environment setting LDFLAGS ineffective after installation stage 1. Any workaround?

[Thierry Moreau]

Dear compiler gurus,

I wish to have executables with the library path 
(-Wl,-rpath=$HOME/tools/lib) embedded.

This is intended to facilitate executables compiled with various 
versions/release candidates/snapshots run without keeping track of 
LD_LIBRARY_PATH. (modifying the specs file seems more intricate than 
setting environment variables for my purpose).

With

export LDFLAGS="-Wl,-rpath-link=$HOME/tools/lib -Wl,-rpath=$HOME/tools/lib"

it works for binutils executables, and application executables created 
with a straightforward autoconf/automake build process.

I can see that the -rpath was effective with
objdump -x $HOME/tools/bin/my_as | grep tools
which reports
RPATH /home/tmoreau/tools/lib

But with the gcc (latest 4.6.1 snapshot), -rpath (requested through 
LDFLAGS as indicated above) is effective only for executables built in 
stage 1 (and fixincl), but not for the installed gcc executables.

Is it intentional that the LDFLAGS environment setting is partially 
effective during gcc build?

Thank in advance.

-- 
- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, QC, Canada H2M 2A1

Tel. +1-514-385-5691

P.S.

Thinking while I write, maybe this has to do with the way recursive 
configure carry (or drop) environment settings (and the fact that gcc 
installation might use recursion mechanisms more creatively than e.g. 
binutils). (Thanks for providing an opportunity to write so I can think!)