GNU bug report logs -
#10704
All GCC "libtool" libraries need relinking during installation on hppa*-*-hpux* (GCC PR target/52098)
Previous Next
Full log
View this message in rfc822 format
The following GCC libraries are incorrectly installed:
libffi.sl, libgcj.sl, libgomp.sl, libobjc.sl, libquadmath.sl,
libssp.sl and libstdc++.sl.
The issue is slightly different on 32 and 64-bit targets, but
essentially the problem is the original links encode rpaths
from the build tree that remain in the installed libraries.
This occurs because "fast install" is used for all libraries
that don't have a dependent libtool library.
Here is an example of an incorrectly installed 32-bit library:
-bash-3.2$ chatr libstdc++.sl
libstdc++.sl:
shared library
shared library dynamic path search:
SHLIB_PATH disabled second
embedded path enabled first /opt/gnu/gcc/gcc-4.6/lib
internal name:
libstdc++.sl.6
shared library list:
dynamic /usr/lib/libm.2
dynamic /mnt/gnu/gcc/obj32dir/./gcc/libgcc_s.4
The dynamic path for libgcc_s.4 is from the original build. The
HP dynamic linker uses the hardcoded path
/mnt/gnu/gcc/obj32dir/./gcc/libgcc_s.4
first and then the embedded path in trying to locate libgcc_s.4.
Searching the hardcoded path is a nuisance and a security issue.
Here is an example of a library which has been correctly installed:
-bash-3.2$ chatr libgfortran.sl
libgfortran.sl:
shared library
shared library dynamic path search:
SHLIB_PATH disabled second
embedded path enabled first /opt/gnu/gcc/gcc-4.6/lib
internal name:
libgfortran.sl.3
shared library list:
dynamic /opt/gnu/gcc/gcc-4.6/lib/libquadmath.sl.0
dynamic /usr/lib/libm.2
dynamic /usr/lib/libc.2
dynamic /opt/gnu/gcc/gcc-4.6/lib/libgcc_s.4
The 64-bit linker doesn't hardcode paths into the library list but the
default behavior is to concatenate -L paths into the embedded path:
-bash-3.2$ chatr libstdc++.sl
libstdc++.sl:
64-bit ELF shared library
shared library dynamic path search:
LD_LIBRARY_PATH enabled first
SHLIB_PATH enabled second
embedded path enabled third
/mnt/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src:/mnt/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src/.libs:/mnt/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src:/mnt/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src/.libs:/mnt/gnu/gcc/objdir/./gcc:/usr/ccs/lib/pa20_64:/opt/langtools/lib/pa20_64:/lib/pa20_64:/usr/lib/pa20_64:/mnt/gnu/gcc/objdir/./gcc:/usr/ccs/lib/pa20_64:/opt/langtools/lib/pa20_64:/lib/pa20_64:/usr/lib/pa20_64
internal name:
libstdc++.sl.6
shared library list:
libm.2
libgcc_s.4
Again libgfortran.sl is an example of a correctly installed library:
-bash-3.2$ chatr libgfortran.sl
libgfortran.sl:
64-bit ELF shared library
shared library dynamic path search:
LD_LIBRARY_PATH enabled first
SHLIB_PATH enabled second
embedded path enabled third /opt/gnu64/gcc/gcc-4.6/lib
internal name:
libgfortran.sl.3
shared library list:
libquadmath.sl.0
libm.2
libc.2
libgcc_s.4
Relinking is the only way I can see to change the hardcoded library paths
for the 32-bit libraries. I think the same could be done for the 64-bit
libraries. However, I believe the +nodefaultrpath and +b path options
could be used on the initial link to generate libraries that are directly
installable.
Dave
--
John David Anglin dave.anglin <at> bell.net
This bug report was last modified 13 years and 142 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.