GNU logs - #10704, boring messages

Message sent to bug-libtool@HIDDEN:

Subject: bug#10704: All GCC "libtool" libraries need relinking during installation on hppa*-*-hpux* (GCC PR target/52098)
Resent-From: John David Anglin <dave.anglin@HIDDEN>
Original-Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Thu, 02 Feb 2012 21:19:01 +0000
Resent-Message-ID: <handler.10704.B.13282175354901 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 10704 <at> debbugs.gnu.org
Message-ID: <4F2AFCF2.2020802@HIDDEN>
Date: Thu, 02 Feb 2012 16:15:30 -0500
From: John David Anglin <dave.anglin@HIDDEN>
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: list
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org

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@HIDDEN

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.428 (Entity 5.428)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: John David Anglin <dave.anglin@HIDDEN>
Subject: bug#10704: Acknowledgement (All GCC "libtool" libraries need
 relinking during installation on hppa*-*-hpux* (GCC PR target/52098))
Message-ID: <handler.10704.B.13282175354901.ack <at> debbugs.gnu.org>
References: <4F2AFCF2.2020802@HIDDEN>
X-Gnu-PR-Message: ack 10704
X-Gnu-PR-Package: libtool
Reply-To: 10704 <at> debbugs.gnu.org
Date: Thu, 02 Feb 2012 21:19:01 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-libtool@HIDDEN

If you wish to submit further information on this problem, please
send it to 10704 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
10704: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D10704
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Last modified: Mon, 25 Nov 2019 12:00:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.