Subject: pkg/4946: perl5.0004 coredumps on lib/filecopy test #8
To: None <firstname.lastname@example.org>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 02/05/1998 17:55:40
>Synopsis: perl5.0004 coredumps on lib/filecopy test #8
>Responsible: gnats-admin (GNATS administrator)
>Arrival-Date: Thu Feb 5 18:05:02 1998
>Originator: Jonathan Stone
>Release: NetBSD 1.3
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
`make test' of perl5.0004 package reports that test lib/filecopy FAILED.
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).
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.