After recently updating libgmp, I find that shared libraries that
were linked against the old version are broken. For example, libtool
links libguile.sl against libgmp.sl.7, /usr/local/lib/libltdl.sl.4,
/usr/lib/libc.1 and /users/gcc/gcc-4.2.0/lib/libgcc_s.sl. I've always
thought linking shared libraries against other shared libraries.
HP recommends never linking shared libraries against libc.
chatr shows we have
512 (hiauly1)dave> chatr libguile.sl
libguile.sl:
shared library
shared library dynamic path search:
SHLIB_PATH disabled second
embedded path enabled first /usr/local/lib
internal name:
libguile.sl.18
shared library list:
static /usr/local/lib/libgmp.sl.7
dynamic /usr/lib/libM.1
static /usr/local/lib/libltdl.sl.4
dynamic /usr/lib/libc.1
dynamic /users/gcc/gcc-4.2.0/lib/libgcc_s.sl
Now, the new version of libgmp.sl has the following global
constructors:
_GLOBAL__DD | 62000|extern|entry |
_GLOBAL__DD | 62048|extern|code |$CODE$
_GLOBAL__DI | 61888|extern|entry |
_GLOBAL__DI | 61936|extern|code |$CODE$
_GLOBAL__FD_libgcc_s_sl_tmp| -4|uext |stub |
_GLOBAL__FD_libgcc_s_sl_tmp| |undef |code |
_GLOBAL__FD_libgmp_sl_7_2| 61688|extern|entry |
_GLOBAL__FD_libgmp_sl_7_2| 61712|extern|code |$CODE$
_GLOBAL__FD_libgmp_sl_7_2| 62024|uext |stub |
_GLOBAL__FI_libgcc_s_sl_tmp| -4|uext |stub |
_GLOBAL__FI_libgcc_s_sl_tmp| |undef |code |
_GLOBAL__FI_libgmp_sl_7_2| 61488|extern|entry |
_GLOBAL__FI_libgmp_sl_7_2| 61512|extern|code |$CODE$
_GLOBAL__FI_libgmp_sl_7_2| 61912|uext |stub |
We have the following constructors in the previous version:
_GLOBAL__DD | 62032|extern|entry |
_GLOBAL__DD | 62080|extern|code |$CODE$
_GLOBAL__DI | 61920|extern|entry |
_GLOBAL__DI | 61968|extern|code |$CODE$
_GLOBAL__FD_libgcc_s_sl_tmp| -4|uext |stub |
_GLOBAL__FD_libgcc_s_sl_tmp| |undef |code |
_GLOBAL__FD_libgmp_sl_7_1| 61736|extern|entry |
_GLOBAL__FD_libgmp_sl_7_1| 61760|extern|code |$CODE$
_GLOBAL__FD_libgmp_sl_7_1| 62056|uext |stub |
_GLOBAL__FI_libgcc_s_sl_tmp| -4|uext |stub |
_GLOBAL__FI_libgcc_s_sl_tmp| |undef |code |
_GLOBAL__FI_libgmp_sl_7_1| 61552|extern|entry |
_GLOBAL__FI_libgmp_sl_7_1| 61576|extern|code |$CODE$
_GLOBAL__FI_libgmp_sl_7_1| 61944|uext |stub |
libguile.sl has:
_GLOBAL__DD | 469364|extern|entry |
_GLOBAL__DD | 469416|extern|code |$CODE$
_GLOBAL__DI | 469244|extern|entry |
_GLOBAL__DI | 469296|extern|code |$CODE$
_GLOBAL__FD_libgcc_s_sl| -4|uext |stub |
_GLOBAL__FD_libgcc_s_sl| |undef |code |
_GLOBAL__FD_libgcc_s_sl_tmp| -4|uext |stub |
_GLOBAL__FD_libgcc_s_sl_tmp| |undef |code |
_GLOBAL__FD_libgmp_sl_7_1| -4|uext |stub |
_GLOBAL__FD_libgmp_sl_7_1| |undef |code |
_GLOBAL__FD_libguile_sl_18_0| 469040|extern|entry |
_GLOBAL__FD_libguile_sl_18_0| 469064|extern|code |$CODE$
_GLOBAL__FD_libguile_sl_18_0| 469388|uext |stub |
_GLOBAL__FD_libltdl_sl_4_0| -4|uext |stub |
_GLOBAL__FD_libltdl_sl_4_0| |undef |code |
_GLOBAL__FI_libgcc_s_sl| -4|uext |stub |
_GLOBAL__FI_libgcc_s_sl| |undef |code |
_GLOBAL__FI_libgcc_s_sl_tmp| -4|uext |stub |
_GLOBAL__FI_libgcc_s_sl_tmp| |undef |code |
_GLOBAL__FI_libgmp_sl_7_1| -4|uext |stub |
_GLOBAL__FI_libgmp_sl_7_1| |undef |code |
_GLOBAL__FI_libguile_sl_18_0| 468840|extern|entry |
_GLOBAL__FI_libguile_sl_18_0| 468864|extern|code |$CODE$
_GLOBAL__FI_libguile_sl_18_0| 469268|uext |stub |
_GLOBAL__FI_libltdl_sl_4_0| -4|uext |stub |
_GLOBAL__FI_libltdl_sl_4_0| |undef |code |
So, the effect of not stripping the version is to hard code a version
dependence into the shared object. It is not possible to do a version
update of a dependent library without relinking all objects which
depend on it.
I believe collect2 needs to strip the version string after .sl as is
currently done for .so.
--
Summary: collect2 doesn't strip .sl version
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
GCC build triplet: hppa*-*-hpux* (32-bit)
GCC host triplet: hppa*-*-hpux* (32-bit)
GCC target triplet: hppa*-*-hpux* (32-bit)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33772
