http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52098
Bug #: 52098
Summary: All GCC "libtool" libraries need relinking during
installation on hppa*-*-hpux*
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dang...@gcc.gnu.org
Host: hppa*-*-hpux*
Target: hppa*-*-hpux*
Build: hppa*-*-hpux*
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.
