[Bug target/52098] New: All GCC "libtool" libraries need relinking during installation on hppa*-*-hpux*

[danglin at gcc dot gnu.org]

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: unassigned@gcc.gnu.org
        ReportedBy: danglin@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.