>  It looks like this was fixed (for perl) on Thursday:

Yes, that does work for perl. But I think you misunderstand my point.
We need a fix that works for all packages, all third-party source, and
all RENAMEs.  Or announce that we give up on trying to compile code
that doesn't have _POSIX_SOURCE. Or -Werror -Wmissing-prototypes.
Or something.

To recap: the RENAMEs silently susbtitute a different external
link-type name, so that we can call, e.g., `stat()' or `sigaction' and
get the new syscall (stat13 or sigaction14), not the old NetbSD-1.1 or
1.2 syscalls.  But (since there's no renaming for c types) the
arguments to the *new* syscall get the `old' struct name, while the
arguments to the `old' syscall get a new, mangled name.
Think of it as a very limited form of name mangling.


The problem is that when the syscall prototypes and the arugments to a
syscall are in different files, third-party code can compile and run
with an inconsistently mangled set of names.  We have an existence
proof: one of the most patholoically portable programs known;) After
that, saying that its not likely to happen isnt very convincing.


Source in the NetBSD tree cant ever lose this way: its compiled with
"-Werror -Wstrict-prototypes -Wmissing-prototypes", so it cant compile
without a prototype in scope. And the only prototype in our tree is
the one with the RENAME.

But source from outside our tree probably isn't compiled with those flags.
So we really need to do an audit for all RENAME mangling, to make sure
the new, mangled names are *ALWAYS* in scope if the new-style struct
names are visible.  From a quick grep, that seems to be
	sigaction
	sigaltstack
	sigreturn

and the sig*set family.  To fix that, patching perl need not apply.
Including <signal.h> in sys/signal.h, if not _KERNEL, would do it
(since its our implementation we could even do #ifndef _SIGNAL_H_).


>Is your pkgsrc up to date?

As of, um, about wednesday:>.  But not really relevant to the wider
point, though.