hi Erik,

This is clearly not an MD problem.  I know for a fact that I built
perl 5.0004 on a pmax late SPring/early summer and it passed all the
tests then.  (well, OK, I had to pull out -lposix, but AFAIk the pkg
subsystem does that too.)

... I hate to ask this, but have you tried fetching the original perl5
source from a standard FTP site and configuring and building it by
hand?  That's the very first thing to try.  (if it works, the problem
is clearly with the pkg subsystem, maybe in some NetBSD customization
patches?)

I'll assume for now that you've tried that and perl5 still fails as
you describe.

And the pmax uses a completely different compiler backend toolchain to
the other ports you've tested.

I haven't made any significant changes to the pmax libc or libm code.
I'll bet a chocolate fish that this is a problem in libc/libm or --
more likely, IMHO --is due to lossage in the compiler.  That's *the*
big common ground which has changed and which might affect so many ports..

My first suspect would be the recent changes to our version of GCC
that were pulled in from the gcc 2.8 pre-release tree to fix various
MD code-generation bugs.  Not saying these introduced a bug, just that
it's the first place to look after building a virgin perl.

The most direct test of this hypothesis is to find a really fast
system, install an old NetBSD 1.2F or 1.2G `comp' distribution set,
and then rebuild more and more of your perl binary with it: first perl
itself, then libm, ....  If you get to rebuilding the world with the
old compiler and you still have a bug, then it's a library change,
somewhere.