[Python-bugs-list] [ python-Bugs-535545 ] make fails at posixmodule.c
noreply@sourceforge.net
noreply@sourceforge.net
Sun, 31 Mar 2002 12:21:29 -0800
Bugs item #535545, was opened at 2002-03-27 02:26
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470
Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Whit Blauvelt (whit)
Assigned to: Martin v. Löwis (loewis)
Summary: make fails at posixmodule.c
Initial Comment:
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I.
-I./Include -DHAVE_CONFIG_H -c
./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function `posix_nice':
./Modules/posixmodule.c:1270: warning: implicit
declaration of function `getpriority'
./Modules/posixmodule.c:1270: `PRIO_PROCESS'
undeclared (first use in this function)
./Modules/posixmodule.c:1270: (Each undeclared
identifier is reported only once
./Modules/posixmodule.c:1270: for each function it
appears in.)
make: *** [Modules/posixmodule.o] Error 1
This using gcc version 2.95.3 on what started life as
a Red Hat 6.0 system.
----------------------------------------------------------------------
>Comment By: Michael Hudson (mwh)
Date: 2002-03-31 20:21
Message:
Logged In: YES
user_id=6656
Martin, what if anything do you think should be done here?
I'm leery of mucking with configure.in at this point.
----------------------------------------------------------------------
Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 17:12
Message:
Logged In: YES
user_id=133413
Have autoconf 2.13. Never explicitly used it though, and
don't know the theory of it. If I patch, then invoke
autoconf, then invoke configure ... well, that may not be
what you mean, because it doesn't get around the problem.
If I just use your new configure file, that doesn't work
either. Please specify the exact steps you require.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2002-03-29 16:35
Message:
Logged In: YES
user_id=21627
If you have autoconf, you can just use the patch to
configure.in, and invoke 'autoconf'. In case you don't have
autoconf, I'll attach the complete configure file.
----------------------------------------------------------------------
Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 16:30
Message:
Logged In: YES
user_id=133413
Um ...
# patch -p1 <../conf.txt
patching file `configure.in'
patching file `configure'
Reversed (or previously applied) patch detected! Assume -R?
[n]
Apply anyway? [n] y
Hunk #1 FAILED at 1.
Hunk #2 FAILED at 1428.
2 out of 267 hunks FAILED -- saving rejects to configure.rej
If I say yes to -R, almost all hunks fail.
***************
*** 1,6 ****
#! /bin/sh
- # From configure.in Revision: 1.288.6.3
# Guess values for system-dependent variables and create
Makefiles.
# Generated automatically using autoconf version 2.13
--- 1,6 ----
#! /bin/sh
+ # From configure.in Revision: 1.288.6.4
# Guess values for system-dependent variables and create
Makefiles.
# Generated automatically using autoconf version 2.13
***************
*** 1428,1434 ****
fi
case $ac_sys_system in
AIX*)
- LINKCC="\/Modules/makexp_aix
Modules/python.exp \\ \; $(LINKCC)";;
dgux*)
LINKCC="LD_RUN_PATH=$libdir $(LINKCC)";;
Monterey64*)
--- 1428,1434 ----
fi
case $ac_sys_system in
AIX*)
+ LINKCC="\/Modules/makexp_aix
Modules/python.exp \\ \; $LINKCC";;
dgux*)
LINKCC="LD_RUN_PATH=$libdir $(LINKCC)";;
Monterey64*)
Well, I'll try it as patched - those hunks don't look like
much is lost.
The config.log doesn't look good:
configure:2016: checking for sys/resource.h
configure:2026: gcc -E conftest.c >/dev/null 2>conftest.out
In file included from /usr/include/sys/resource.h:25,
from configure:2022:
/usr/include/bits/resource.h:109: warning: `RLIM_INFINITY'
redefined
/usr/include/asm/resource.h:26: warning: this is the
location of the previous definition
configure: failed program was:
#line 2021 "configure"
#include "confdefs.h"
#include <sys/resource.h>
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2002-03-29 15:58
Message:
Logged In: YES
user_id=21627
Please try the attached conf.txt with an otherwise
unmodified system, and report whether it solves the problem.
----------------------------------------------------------------------
Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 04:33
Message:
Logged In: YES
user_id=133413
Probably not wisely, I tried changing the definition of
RLIM_INFINITY in bits/resource.h to match that in the kernel
header. That took Python through the install, with make
test producing:
166 tests OK.
1 test failed:
test_mmap
20 tests skipped:
test_al test_cd test_cl test_curses test_dl test_gl
test_imgfile
test_largefile test_linuxaudiodev test_minidom test_nis
test_ntpath test_pyexpat test_sax test_socket_ssl
test_socketserver test_sunaudiodev test_unicode_file
test_winreg
test_winsound
4 skips unexpected on linux2:
test_minidom test_linuxaudiodev test_pyexpat test_sax
make: *** [test] Error 1
As I understand all this, the definition to prefer should
probably be the one from glibc rather than the kernel (if it
even makes a difference on this value). Is this the one
which would be in effect if Python's configure were simply
to accept that resource.h is present rather than rejecting
it for this difference?
RLIM_INFINITY btw is changed to match more recent kernels in
glibc 2.2 - but there's no rpm of that for Red Hat 6.x, and
of course building your own glibc is a good way to break a
system.
----------------------------------------------------------------------
Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 23:03
Message:
Logged In: YES
user_id=133413
A Google search leads me to a comment from Linus himself
explaining that all the distributions symlinking like Red
Hat 6.0 did are broken. I'm sure his theory is right, but
out here in the real world, as he notes, many distros do
that and most of us do have the idea that the current
kernel should be built in /usr/src/linux. (Seems that rpms
and debs of kernels put new kernel code there too - but
I've always built kernels from tar.)
Anyway, Linus's take is at:
http://www.uwsg.iu.edu/hypermail/linux/kernel/0007.3/0587.html
----------------------------------------------------------------------
Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 22:43
Message:
Logged In: YES
user_id=133413
You have good instincts on what to believe. I was mislead
because rerunning configure produces a config.log without
the warnings about resource.h. However running it in a
freshly openned tar reproduces that warning; and even
running it twice there (the second time, no warning)
results in compilation failing at the same place.
So I think you have it - configure takes _any_ gcc warning
as indicating nonexistence. And I think I see why the
conflict comes on some systems but not on others. Red Hat
6.0 sets /usr/include/asm as follows:
asm -> ../src/linux/include/asm/
That directory includes a "resource.h". On this box that
happens to be code included with kernel 2.4.16, largely
consisting of a modified definition of RLIM_INFINITY. I'd
guess if the box still had a 2.2 kernel there would be no
gcc warning. The whole of that file is:
#ifndef _I386_RESOURCE_H
#define _I386_RESOURCE_H
/*
* Resource limits
*/
#define RLIMIT_CPU 0 /* CPU time in ms
*/
#define RLIMIT_FSIZE 1 /* Maximum
filesize */
#define RLIMIT_DATA 2 /* max data size */
#define RLIMIT_STACK 3 /* max stack size
*/
#define RLIMIT_CORE 4 /* max core file
size */
#define RLIMIT_RSS 5 /* max resident
set size */
#define RLIMIT_NPROC 6 /* max number of
processes */
#define RLIMIT_NOFILE 7 /* max number of
open files */
#define RLIMIT_MEMLOCK 8 /* max
locked-in-memory address space */
#define RLIMIT_AS 9 /* address space
limit */
#define RLIMIT_LOCKS 10 /* maximum file
locks held */
#define RLIM_NLIMITS 11
/*
* SuS says limits have to be unsigned.
* Which makes a ton more sense anyway.
*/
#define RLIM_INFINITY (~0UL)
#ifdef __KERNEL__
#define INIT_RLIMITS { { RLIM_INFINITY, RLIM_INFINITY }, { RLIM_INFINITY, RLIM_INFINITY }, { RLIM_INFINITY, RLIM_INFINITY }, { _STK_LIM, RLIM_INFINITY }, { 0, RLIM_INFINITY }, { RLIM_INFINITY, RLIM_INFINITY }, { 0, 0 }, { INR_OPEN, INR_OPEN }, { RLIM_INFINITY, RLIM_INFINITY }, { RLIM_INFINITY, RLIM_INFINITY }, { RLIM_INFINITY, RLIM_INFINITY }, }
#endif /* __KERNEL__ */
#endif
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 21:08
Message:
Logged In: YES
user_id=21627
This is hard to believe: the spaces should have no effect.
Please consider the config.log analysis of the problem:
/usr/include/bits/resource.h:109: warning: `RLIM_INFINITY'
redefined
/usr/include/asm/resource.h:26: warning: this is the
location of the previous definition
Apparently, configure treats these warnings as an indication
that sys/resource.h is absent. config.log also gives the
"program" it tried to compile - if your theory is correct,
changing the spaces should silence the gcc warning. Could
you please verify this theory (i.e. compiling the program
#include <sys/resource.h>
both with the original and the modified resource.h)
It appears that configure should disable warnings in gcc;
I'll try to come up with a patch.
----------------------------------------------------------------------
Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 17:20
Message:
Logged In: YES
user_id=133413
Think you've led me to the problem.
/usr/include/bits/resource.h has:
/* Value to indicate that there is no limit. */
#ifndef __USE_FILE_OFFSET64
# define RLIM_INFINITY ((long int)(~0UL >> 1))
#else
# define RLIM_INFINITY 0x7fffffffffffffffLL
#endif
#ifdef __USE_LARGEFILE64
# define RLIM64_INFINITY 0x7fffffffffffffffLL
#endif
Removing the spaces after "#" before "define" results in
configure correctly recognizing resource.h. Then the
question would be: is this a shortcoming of configure, or
are those spaces actually disabling bugs in this version
of bits/resource.h?
----------------------------------------------------------------------
Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 16:56
Message:
Logged In: YES
user_id=133413
Right, HAVE_SYS_RESOURCE_H is commented out.
config.log attached.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 16:42
Message:
Logged In: YES
user_id=21627
Thanks, now we are getting somewhere. It appears that
pyconfig.h does not define HAVE_SYS_RESOURCE_H on your
system (can you confirm this? it should be commented out).
Since you reported earlier that that
/usr/include/sys/resource.h *is* present, it seems that
configure has not properly detected this fact. Can you
please attach the config.log also?
----------------------------------------------------------------------
Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 16:02
Message:
Logged In: YES
user_id=133413
Here it is.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 15:38
Message:
Logged In: YES
user_id=21627
Unfortunately, I still can't see what is causing this
problem. Can you please regenerate posixmodule.i once more,
this time adding "--save-temps -dD"? That will give all
preprocessor defines.
----------------------------------------------------------------------
Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 13:13
Message:
Logged In: YES
user_id=133413
Honest, it was checked. But here we go (again)...
Oh error: "File Upload: ArtifactFile: File must be > 20
bytes and < 256000 bytes in length" and the size is 361734
- time to compress
----------------------------------------------------------------------
Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 13:10
Message:
Logged In: YES
user_id=133413
Honest, it was checked. But here we go (again)...
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 10:17
Message:
Logged In: YES
user_id=21627
Unfortunately, it is not attached; please check the checkbox.
----------------------------------------------------------------------
Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 00:35
Message:
Logged In: YES
user_id=133413
Attached is the end of the stderr output and
posixmodule.i (combined in 1 file)
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 00:06
Message:
Logged In: YES
user_id=21627
I can't reproduce the problem on a similarly-configured machine.
Can you please add the options --trace-includes --save-temps
to the gcc command line? The first one will produce a lot of
output to stderr, the other will produce posixmodule.i.
Please attach both to the report.
----------------------------------------------------------------------
Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 19:17
Message:
Logged In: YES
user_id=133413
I'm _not_ certain about header files. The fragments you
ask about are there _except_ for
#define PRIO_PROCESS PRIO_PROCESS
The file is attached. I don't need a fix at this point,
but if it's worth fixing for others ... or knowing what to
specify as the system requirement here....
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 16:34
Message:
Logged In: YES
user_id=21627
Are you sure you have installed the header files for this C
library as well? Can you please attach your copy or
/usr/include/bits/resource.h to this report? It should
contain the fragment
PRIO_PROCESS = 0, /* WHO is a process ID. */
#define PRIO_PROCESS PRIO_PROCESS
Furthermore, /usr/include/sys/resource.h should contain the
fragment
/* Get the system-dependent definitions of structures and
bit values. */
#include <bits/resource.h>
If you are not interested in investigating this further,
that would be fine as well.
----------------------------------------------------------------------
Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 15:33
Message:
Logged In: YES
user_id=133413
glibc-2.1.3-15.i386.rpm
If by PRIO_ constants you mean shell variables(?), none.
Python configure reports "checking for getpriority yes"
Each of the 2.x series fails to compile at that same point.
1.52 had no problem - and is all I actually needed at this
point.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 12:21
Message:
Logged In: YES
user_id=21627
What is the glibc release that you use? What PRIO_ constants
are defined on your system? Do you have the getpriority call?
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470