Discussion:
Environment setting LDFLAGS ineffective after installation stage 1. Any workaround?
Thierry Moreau
2011-05-31 18:29:48 UTC
Permalink
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!)
Marc Glisse
2011-05-31 18:30:54 UTC
Permalink
(gcc-help ?)
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?
Yes. For further stages, there is BOOT_LDFLAGS. There is also a configure
option with a similar name.
--with-stage1-ldflags=
--with-boot-ldflags=

see:
http://gcc.gnu.org/install/configure.html
--
Marc Glisse
Thierry Moreau
2011-06-01 13:23:45 UTC
Permalink
Post by Marc Glisse
(gcc-help ?)
Post by Thierry Moreau
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?
Yes. For further stages, there is BOOT_LDFLAGS. There is also a
configure option with a similar name.
--with-stage1-ldflags=
--with-boot-ldflags=
http://gcc.gnu.org/install/configure.html
Thanks,

Indeed,
-with-boot-ldflags="-Wl,-rpath-link=$HOME/tools/lib
-Wl,-rpath=$HOME/tools/lib"

did allow me to get gcc executables with embedded references to shared
library directory.

Less dependency on ldconfig and/or LD_LIBRARY_PATH, but more dependency
on exact library files being accessible as long as the executables are
present.
--
- Thierry Moreau

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

Tel. +1-514-385-5691
Loading...