public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug driver/33772] New: collect2 doesn't strip .sl version
@ 2007-10-14 21:07 danglin at gcc dot gnu dot org
2007-10-18 23:56 ` [Bug driver/33772] " dave at hiauly1 dot hia dot nrc dot ca
0 siblings, 1 reply; 2+ messages in thread
From: danglin at gcc dot gnu dot org @ 2007-10-14 21:07 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 2+ messages in thread
* [Bug driver/33772] collect2 doesn't strip .sl version
2007-10-14 21:07 [Bug driver/33772] New: collect2 doesn't strip .sl version danglin at gcc dot gnu dot org
@ 2007-10-18 23:56 ` dave at hiauly1 dot hia dot nrc dot ca
0 siblings, 0 replies; 2+ messages in thread
From: dave at hiauly1 dot hia dot nrc dot ca @ 2007-10-18 23:56 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-18 23:55 -------
Subject: Re: New: collect2 doesn't strip .sl version
On Sun, 14 Oct 2007, danglin at gcc dot gnu dot org wrote:
> 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.
The reason previously installed libraries break is the dependent libraries
have hardcoded dependencies on the `*GLOBAL*' symbols used for constructors,
destructors and EH exception support (hppa2.0w-hp-hpux* currently has
its EH data in the data section).
The attached patch fixes the versioning problem. However, we still have
a random portion in every `*GLOBAL_F*' symbol. This can easily change
from one build to the next. So, I'm thinking we need to bury them
in special sections similar to .init_array and .fini_array. However,
the dynamic loader doesn't provide direct support for this, so this
it's going to take some thinking as to the best way to do this.
Dave
------- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-18 23:55 -------
Created an attachment (id=14371)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14371&action=view)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33772
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2007-10-18 23:56 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-10-14 21:07 [Bug driver/33772] New: collect2 doesn't strip .sl version danglin at gcc dot gnu dot org
2007-10-18 23:56 ` [Bug driver/33772] " dave at hiauly1 dot hia dot nrc dot ca
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).