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

noreply@sourceforge.net noreply@sourceforge.net
Tue, 02 Apr 2002 00:44:46 -0800


Bugs item #535545, was opened at 2002-03-27 03: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
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: Martin v. Löwis (loewis)
Date: 2002-04-02 10:44

Message:
Logged In: YES 
user_id=21627

For 2.2.1, no action is needed - this is a system
configuration problem. 

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

Comment By: Michael Hudson (mwh)
Date: 2002-03-31 22: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 18: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 17: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 17: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 16: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 05: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-29 00: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 23: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 22: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 18: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 17: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 17: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 17:02

Message:
Logged In: YES 
user_id=133413

Here it is.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 16: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 14: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 14: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 11: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 01: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 01: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 20: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 17: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 16: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 13: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