GNU bug report logs - #10704
All GCC "libtool" libraries need relinking during installation on hppa*-*-hpux* (GCC PR target/52098)

Previous Next

Package: libtool;

Reported by: John David Anglin <dave.anglin <at> bell.net>

Date: Thu, 2 Feb 2012 21:19:01 UTC

Severity: normal

To reply to this bug, email your comments to 10704 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-libtool <at> gnu.org:
bug#10704; Package libtool. (Thu, 02 Feb 2012 21:19:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to John David Anglin <dave.anglin <at> bell.net>:
New bug report received and forwarded. Copy sent to bug-libtool <at> gnu.org. (Thu, 02 Feb 2012 21:19:01 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: John David Anglin <dave.anglin <at> bell.net>
To: bug-libtool <at> gnu.org
Subject: All GCC "libtool" libraries need relinking during installation on
	hppa*-*-hpux* (GCC PR target/52098)
Date: Thu, 02 Feb 2012 16:15:30 -0500
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.