This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
libgmp, libmpfr, RPATH, RUNPATH, LD_LIBRARY_PATH and gcc build options
- From: "Poor Yorick" <org dot gnu dot gcc dot help at pooryorick dot com>
- To: gcc-help at gnu dot org
- Date: Sat, 05 Jan 2008 22:40:42 +0000
- Subject: libgmp, libmpfr, RPATH, RUNPATH, LD_LIBRARY_PATH and gcc build options
- Reply-to: "Poor Yorick" <org dot gnu dot gcc dot help at pooryorick dot com>
This is a followup to my previous question about RPATH and RUNPATH in gcc
binaries:
http://gcc.gnu.org/ml/gcc-help/2008-01/msg00028.html
I built and installed gcc to an NFS mount and used it to build and install a
stack of software packages in the same area. LD_LIBRARY_PATH is not used in
the environment, and because they can't use DT_RPATH and DT_RUNPATH, gcc
binaries were the only programs which couldn't find the correct libgmp and
libmpfr. It seemed like the only good solution was to build gcc with static
libgmp and libmpfr, but if shared versions of those libraries exist, they get
used when building gcc, and there is no option to request the static
libraries. To work around this issue, I hid libgmp.so and libmpfr.so before
building gcc. This is an excerpt from my build script:
config_pre () {
#can't embed RUNPATH or RPATH into gcc binaries
# so make sure it builds with static gmp and mpfr
for i in 'libgmp.so*' 'libmpfr.so*'; do
find ../lib -iname "$i" | while read; do
mv "$REPLY" "$REPLY".hide
done
done
}
link_pre () {
#unhide libgmp and libmpfr
for i in 'libgmp.so*.hide' 'libmpfr.so*.hide'; do
find ../lib -iname "$i" | while read; do
mv "$REPLY" "${REPLY%.hide}"
done
done
}
Perhaps this will help someone who finds themselves in the same boat. How about adding some configure options like --with-static-gmp and --with-static-mpfr to gcc? Also, now that gcc binaries depend on external libraries, why not allow DT_RPATH and DT_RUNPATH into them?
--
Yorick