On hppa-hpux (32bit SOM, and likely 64bit ELF), installed libgcc_s.sl is
symlinked to libgcc_s.4, but does not have an 'internal name' (=soname) set.
So binaries linked against libgcc_s.sl have "libgcc_s.sl" encoded as dependent
library, while it should be "libgcc_s.4" instead.
As a result, the runtime loader searches for "libgcc_s.0" first (which is a
compatibility thingy by hpux) and "libgcc_s.sl" second, instead of
"libgcc_s.4".
AFAICS, gcc/config/pa/t-hpux-shlib should get something like this patch:
SHLIB_LINK = $(GCC_FOR_TARGET) $(LIBGCC2_CFLAGS) -shared -nodefaultlibs \
+ -Wl,+h -Wl,$(SHLIB_SONAME) \
-o $(SHLIB_DIR)/$(SHLIB_NAME).tmp @multilib_flags@ $(SHLIB_OBJS) && \
Or is there a reason to not set the 'internal name' I just didn't find?
Thank you!
--
Summary: hppa-hpux: libgcc_s.sl does not have the 'internal name'
(=soname) set
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michael dot haubenwallner at salomon dot at
GCC build triplet: hppa2.0w-hp-hpux11.31
GCC host triplet: hppa2.0w-hp-hpux11.31
GCC target triplet: hppa2.0w-hp-hpux11.31
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40913
