[Python-bugs-list] [ python-Bugs-535545 ] make fails at posixmodule.c

noreply@sourceforge.net noreply@sourceforge.net
Thu, 28 Mar 2002 15:03:15 -0800


Bugs item #535545, was opened at 2002-03-26 21: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: Nobody/Anonymous (nobody)
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: Whit Blauvelt (whit)
Date: 2002-03-28 18: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 17: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 16: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 12: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 11: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 11: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 11:02

Message:
Logged In: YES 
user_id=133413

Here it is.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 10: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 08: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 08: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 05: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-27 19: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-27 19: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 14: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 11: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 10: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 07: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