Subject: port-pmax/4947: multiply-defined symbols in mips ELF shared libraries lose
To: None <>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: netbsd-bugs
Date: 02/05/1998 21:19:01
>Number:         4947
>Category:       port-pmax
>Synopsis:       multiply-defined symbols in mips ELF shared libraries lose
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    gnats-admin (GNATS administrator)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>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
application's malloc().
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
   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