Subject: port-pmax/4947: multiply-defined symbols in mips ELF shared libraries lose
To: None <email@example.com>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 02/05/1998 21:19:01
>Synopsis: multiply-defined symbols in mips ELF shared libraries lose
>Responsible: gnats-admin (GNATS administrator)
>Arrival-Date: Thu Feb 5 21:20:02 1998
>Originator: Jonathan Stone
>Release: NetBSD 1.3 binary release
System: NetBSD Reno.DSG.Stanford.EDU 1.3 NetBSD 1.3 (GENERIC) #2: Tue Dec 30 01:16:36 PST 1997 jonathan@Reno.DSG.Stanford.EDU:/reno/compile/GENERIC pmax
Executables linked against shared libraries which use a symbol (e.g.,
malloc) defined more than once (e.g., in both libc and in either the
application or libgnumalloc) don't work as expected.
Binaries end up either coredumping when they call such a symbol, or
call an application-provided free() wiht storage not allocated by the
I'm morally certain these are all the same bug.
This bug manifests itself in several ways:
a) Build tcsh from the NetBSD package (as of 1997-02-04), i.e. using
tcsh's own malloc(). Doing test -Q shows tcsh is calling tcsh' free()
with spacenot allocated by tcsh' mallocc().
Using either -DSYS_MALLOC or linking statically fixes the problem.
b) Build the X11R6.3 xterm's helper application, resize, with gnumalloc.
run it in an xterm and watch it coredump.
If linked without libgnumalloc, the app work fine.
c) Perl 5.0004 on NetBSD searches for and finds libposix.an
The NetBSD libposix contains a POSIX-ised rename(2).
Calling that rename() from a perl binary causes perl to coredump--
e.g., by running the lib/filecopy test. (See PR pkg/4946 for details).
If linked statically or linked withOUT libposix, perl5 passes
its test harness with perfect colors.
No fix for this bug is known, only application-specific workarounds.
It sounds awfully like a bug in either the linker, ld (perhaps binding
references within a library, to a funciton provided in that library,
directly to the library's own definition, rather than via the GOT?),
or in ld.so.