>Number:         4946
>Category:       pkg
>Synopsis:       perl5.0004 coredumps on  lib/filecopy test #8
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    gnats-admin (GNATS administrator)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Feb  5 18:05:02 1998
>Last-Modified:
>Originator:     Jonathan Stone
>Organization:
	
>Release:        NetBSD 1.3
>Environment:
	
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


>Description:

`make test' of perl5.0004 package reports that test lib/filecopy FAILED.

>How-To-Repeat:
	cd /usr/pkgsrc/lang/perl5; make ; make test

Rerunning `( cd ./t ; ./perl lib/filecopy.t)') shows that test 8 is
causing perl to coredump.  Looking at the corefile suggests the
problem is calling rename(2).


>Fix:

I beleive the package maintainers were aware of this, but there
appears to be a bug with redundantly-defined symbols in shared
libraries on NetBSD/pmax.  (e.g., rename(2) is defined in both libc
and in lposix).  The symptom is that a process wil coredumps when it
calls the redundantly-defined symbol.

(I'm told OpenBSD/arc loses similarly).

Here, rename(2) is defined in both -lposix and libc is what triggers
the Perl coredump.  Editing out the `-lposix' from the configured
Makefile _by hand_ and relinking and rerunning perl fixes the
coredump.  The result passes Perl's `make test'.

It'd be very, very nice if the NetBSD package could fix that in the
Perl-geenrated Makefile on NetBSD/pmax systems, at least until the
apparent dynamic-linker bug is resolved.

I'd sooner that Perl on pmaxes used the BSD semantics rather than
coredumping, but I don't know of a good way around this that doesn't
affect all NetBSD ports.
>Audit-Trail:
>Unformatted: