I was trying to get FreeBSD 4.2-BETA to compile under FreeBSD 3.4 when
I found that the use of the new setresgid() and setresuid() system
calls were causing the perl5 compile to fail. I got around this using
NOPERL=yup but while investigating I noticed an apparent bug in the use
of setresgid() and propose this patch:
Index: mg.c
===================================================================
RCS file: /cvs/src/contrib/perl5/mg.c,v
retrieving revision 1.1.1.4
diff -u -r1.1.1.4 mg.c
--- mg.c 2000/08/20 08:42:14 1.1.1.4
+++ mg.c 2000/11/22 12:01:32
@@ -1926,7 +1926,7 @@
(void)setregid((Gid_t)PL_gid, (Gid_t)-1);
#else
#ifdef HAS_SETRESGID
- (void)setresgid((Gid_t)PL_gid, (Gid_t)-1, (Gid_t) 1);
+ (void)setresgid((Gid_t)PL_gid, (Gid_t)-1, (Gid_t)-1);
#else
if (PL_gid == PL_egid) /* special case $( = $) */
(void)PerlProc_setgid(PL_gid);
I assume this was just a typo. I can't think of any reason to try to
set the saved uid to daemon. I'd whip in and commit this myself, but
I'm sure there are "vendor branch considerations", and I've never
found out what's involved with that.
And piggybacking a slightly wider issue: The cross-tools section of
Makefile.inc1 is supposed to address the use of new system calls and
such in build tools, right? Can we forget about the old "try to use
the new syscall and do something else if it isn't there" code? And all
we need to do to fix my migration problem is to MFC marcel's miniperl
cross-build fix? Right?
Otherwise I have all this blather I was going to say about using fancy
new syscalls in perl just to emulate old syscalls we already have, and
the way that makes upgrading harder. But I don't have to go on about
that, it seems. :-)
Stephen.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
