[perl #36951] POSIX build fails in bleadperl
# New Ticket Created by David Dyck
# Please include the string: [perl #36951]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36951
This is a bug report for perl from [EMAIL PROTECTED],
generated with the help of perlbug 1.35 running under perl vv5.9.3.
-
[Please enter your report here]
Just rsync'ed to the latest blead perl as was surprised
to get the following error (haven't dug through the diff's
to find out what might have triggered this)
Making POSIX (dynamic)
/home/dcd/CPAN/debug/ext/POSIX
Processing hints file hints/linux.pl
Note (probably harmless): No library found for -lposix
Note (probably harmless): No library found for -lcposix
Writing Makefile for POSIX
make[1]: Entering directory `/hdd1/jd/usr2/dcd/CPAN/debug/ext/POSIX'
make[1]: Leaving directory `/hdd1/jd/usr2/dcd/CPAN/debug/ext/POSIX'
make[1]: Entering directory `/hdd1/jd/usr2/dcd/CPAN/debug/ext/POSIX'
cp POSIX.pod ../../lib/POSIX.pod
cp POSIX.pm ../../lib/POSIX.pm
AutoSplitting ../../lib/POSIX.pm (../../lib/auto/POSIX)
../../miniperl -I../../lib -I../../lib ../../lib/ExtUtils/xsubpp
-noprototypes -typemap ../../lib/ExtUtils/typemap -typem
ap typemap POSIX.xs POSIX.xsc mv POSIX.xsc POSIX.c
cc -c -DPERL_DISABLE_PMC -DDEBUGGING -fno-strict-aliasing -pipe
-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BIT
S=64 -DSTRUCT_TM_HASZONE -DHINT_SC_EXIST -O3 -g -DVERSION=\1.09\
-DXS_VERSION=\1.09\ -fpic -I../.. POSIX.c
const-c.inc: In function `constant_8':
In file included from POSIX.xs:395:
const-c.inc:2010: `_NSIG' undeclared (first use in this function)
const-c.inc:2010: (Each undeclared identifier is reported only once
const-c.inc:2010: for each function it appears in.)
make[1]: *** [POSIX.o] Error 1
make[1]: Leaving directory `/hdd1/jd/usr2/dcd/CPAN/debug/ext/POSIX'
make: *** [lib/auto/POSIX/POSIX.so] Error 2
#define PERL_REVISION 5 /* age */
#define PERL_VERSION9 /* epoch */
#define PERL_SUBVERSION 3 /* generation */
static const char * const local_patches[] = {
NULL
,DEVEL24148
,NULL
};
[Please do not change anything below this line]
-
---
Flags:
category=library
severity=high
---
This perlbug was built using Perl vv5.9.3 - Thu Aug 18 21:10:10 PDT 2005
It is being executed now by Perl vv5.9.3 - Wed Jul 6 21:34:06 PDT 2005.
Site configuration information for perl vv5.9.3:
Configured by dcd at Wed Jul 6 21:34:06 PDT 2005.
Summary of my perl5 (revision 5 version 9 subversion 3 patch 25088)
configuration:
Platform:
osname=linux, osvers=2.4.32-pre1, archname=i686-linux
uname='linux dd 2.4.32-pre1 #1 wed jul 6 15:56:53 pdt 2005 i686 '
config_args='-Accflags=-DPERL_DISABLE_PMC -Dmksymlinks -Dinstallusrbinperl
-Uversiononly -Dusedevel -Doptimize=-O3 -g -de [EMAIL PROTECTED]'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef useithreads=undef usemultiplicity=undef
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-DPERL_DISABLE_PMC -DDEBUGGING -fno-strict-aliasing
-pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-O3 -g',
cppflags='-DPERL_DISABLE_PMC -DDEBUGGING -fno-strict-aliasing -pipe
-I/usr/local/include'
ccversion='', gccversion='egcs-2.91.66.1 19990314/Linux (egcs-1.1.2
release)', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=4
alignbytes=4, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lgdbm -ldbm -ldb -ldl -lm -lc
perllibs=-ldl -lm -lc
libc=/lib/libc.so.5.4.44, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'
Locally applied patches:
---
@INC for perl vv5.9.3:
/usr/local/lib/perl5/5.9.3/i686-linux
/usr/local/lib/perl5/5.9.3
/usr/local/lib/perl5/site_perl/5.9.3/i686-linux
/usr/local/lib/perl5/site_perl/5.9.3
/usr/local/lib/perl5/site_perl/5.9.2/i686-linux
/usr/local/lib/perl5/site_perl/5.9.2
/usr/local/lib/perl5/site_perl
.
---
Environment for perl vv5.9.3:
HOME=/home/dcd
LANG (unset)
LANGUAGE (unset)
LD_LIBRARY_PATH (unset)
LOGDIR (unset)
Re: [perl #36951] POSIX build fails in bleadperl
David Dyck (via RT) wrote: Just rsync'ed to the latest blead perl as was surprised to get the following error (haven't dug through the diff's to find out what might have triggered this) Worksforme. Is this a clean build ?
Re: [perl #36951] POSIX build fails in bleadperl
On Fri, 19 Aug 2005 at 12:07 +0200, Rafael Garcia-Suarez [EMAIL PROTECTED]: From: Rafael Garcia-Suarez [EMAIL PROTECTED] David Dyck (via RT) wrote: Just rsync'ed to the latest blead perl as was surprised to get the following error (haven't dug through the diff's to find out what might have triggered this) Worksforme. Is this a clean build ? Yes. This is an older libc5 base 'slackware' system with a 2.4.32-pre1 kernel that has had trouble with signals before. I think special code had been added to configure to test all the signals individually. I was surprised when these failures occured in the POSIX build - even though miniperl build fine.
Re: [perl #36951] POSIX build fails in bleadperl (RTMAX patch)
On Fri, 19 Aug 2005 at 08:24 -0700, David Dyck [EMAIL PROTECTED] wrote:
On Fri, 19 Aug 2005 at 12:07 +0200, Rafael Garcia-Suarez
[EMAIL PROTECTED]:
From: Rafael Garcia-Suarez [EMAIL PROTECTED]
David Dyck (via RT) wrote:
Just rsync'ed to the latest blead perl as was surprised
to get the following error (haven't dug through the diff's
to find out what might have triggered this)
Worksforme. Is this a clean build ?
Yes. This is an older libc5 base 'slackware' system with
a 2.4.32-pre1 kernel that has had trouble with signals
before. I think special code had been added to configure
to test all the signals individually. I was surprised when
these failures occured in the POSIX build - even though miniperl
build fine.
Just wanted to collect some more info for this bug report
The error
const-c.inc:2010: `_NSIG' undeclared (first use in this function)
is from the lines
#ifdef SIGRTMAX
*iv_return = SIGRTMAX;
return PERL_constant_ISIV;
#else
return PERL_constant_NOTDEF;
#endif
where my asm/signal.h (inherited libc5 style
from the 2.4 kernel sources) has SIGRTMAX
/* These should not be considered constants from userland. */
#define SIGRTMIN32
#define SIGRTMAX(_NSIG-1)
but _NSIG is only defined when compiling the kernel (#ifdef __KERNEL__)
sig_name
Configure tests for, and doesn't place RTMAX in sig_name
$ perl -le ' use Config; print $Config{sig_name}'
reports:
ZERO HUP INT QUIT ILL TRAP ABRT BUS FPE KILL USR1 SEGV USR2 PIPE ALRM
TERM STKFLT CHLD CONT STOP TSTP TTIN TTOU URG XCPU XFSZ VTALRM PROF
WINCH IO PWR SYS CLD IOT POLL UNUSED
So now I'm wondering, why if Configure knows which signal names
are valid, does ext/POSIX/Makefile.pl seem to ignore this.
It looks like the patch triggered the problem, and since
I hadn't rebuild my perl since July 6, I didn't notice it till
now.
+
+[ 25185] By: merijnon 2005/07/19 11:06:22
+Log: Subject: [PATCH] allow POSIX SIGRTMIN...SIGRTMAX signals (and
plug a core dump)
+ From: Jarkko Hietaniemi [EMAIL PROTECTED]
+ Date: Tue, 19 Jul 2005 12:06:00 +0300
+ Message-ID: [EMAIL PROTECTED]
+ Branch: perl
+ ! Configure ext/POSIX/Makefile.PL ext/POSIX/POSIX.pm
+ ! ext/POSIX/POSIX.pod ext/POSIX/POSIX.xs ext/POSIX/t/sigaction.t
+ ! handy.h
Re: [perl #36951] POSIX build fails in bleadperl (RTMAX patch)
On Fri, 19 Aug 2005, David Dyck wrote: Yes. This is an older libc5 base 'slackware' system with a 2.4.32-pre1 kernel that has had trouble with signals before. I think special code had been added to configure to test all the signals individually. I was surprised when these failures occured in the POSIX build - even though miniperl build fine. Just wanted to collect some more info for this bug report The error const-c.inc:2010: `_NSIG' undeclared (first use in this function) is from the lines #ifdef SIGRTMAX *iv_return = SIGRTMAX; return PERL_constant_ISIV; #else return PERL_constant_NOTDEF; #endif where my asm/signal.h (inherited libc5 style from the 2.4 kernel sources) has SIGRTMAX /* These should not be considered constants from userland. */ #define SIGRTMIN32 #define SIGRTMAX(_NSIG-1) In newer glibc2-based systems, SIGRTMAX is defined to be a C library function: __libc_current_sigrtmax(). but _NSIG is only defined when compiling the kernel (#ifdef __KERNEL__) only on such hybrid 2.4.x/libc5 systems, I'd bet. I'd call this a bug in the headers, but we should still work around it. Yes, Configure has previously tested each individual signal, but it's not stored as a really simple config.h #ifdef. One could do a runtime lookup for the string RTMAX in the sign_name[] array, I suppose. It'd probably work just as well to change the test to something like the following to ensure that SIGRTMAX is indeed set to something numeric. #if defined(SIGRTMAX) SIGRTMAX SIGRTMIN -- Andy Dougherty [EMAIL PROTECTED]
