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.

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?

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.

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.

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....

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.

Logged In: YES 
user_id=133413

Attached is the end of the stderr output and 
posixmodule.i (combined in 1 file)

Logged In: YES 
user_id=21627

Unfortunately, it is not attached; please check the checkbox.

Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...

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

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.

Logged In: YES 
user_id=133413

Here it is.

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? 

Logged In: YES 
user_id=133413

Right, HAVE_SYS_RESOURCE_H is commented out.

config.log attached.

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? 

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.

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

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

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.

Logged In: YES 
user_id=21627

Please try the attached conf.txt with an otherwise
unmodified system, and report whether it solves the problem.

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="\$(srcdir)/Modules/makexp_aix
Modules/python.exp \"\" \$(LIBRARY); $(LINKCC)";;
        dgux*)
           LINKCC="LD_RUN_PATH=$libdir $(LINKCC)";;
        Monterey64*)
--- 1428,1434 ----
          fi      
        case $ac_sys_system in
        AIX*)
+          LINKCC="\$(srcdir)/Modules/makexp_aix
Modules/python.exp \"\" \$(LIBRARY); $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>

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.

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.

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.

Logged In: YES 
user_id=21627

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

Logged In: YES 
user_id=21627

Whit, are you still interested in resolving this? If so, I
need to know the precise source distribution that you are
using, so I can produce patches against it.

Logged In: YES 
user_id=133413

Since the problem comes from the way Red Hat 6.0 symlinks
the kernel libraries, which then creates a conflict between
library files if a kernel is compiled from source in the old
standard location of /usr/src/linux (don't think it would
apply to installing kernels from RPM since I don't think Red
Hat ever came up with a path to upgrade 6.0 to a 2.4 kernel
without upgrading the whole distribution) ... hmm, wonder if
that's precise enough for your purposes. There are various
system components upgraded from RPM after the base 6.0
release for security concerns and so on, so if the fix
wouldn't be generic to "6.0 + custom-compiled kernel in
/usr/src/linux" then this system probably couldn't be
defined precisely enough for the purpose.

Logged In: YES 
user_id=21627

I'm still trying to find out why you could not apply the
patch I created earlier on. I want to recreate it so that it
works for your copy of the Python source code, but for that
to work, I need to know what version the copy of your Python
source code has.

Logged In: YES 
user_id=133413

Oh, Python version. By coincidence I just cleaned that from
the system last week, and don't remember the exact version.
Would it make sense for me to try to compile the latest
Python source, see if it fails the same way?

Logged In: YES 
user_id=21627

Yes, please: start with a clean 2.2.1 tree. I have
regenerated the configure for 2.2.1, and attached to this
report.

Logged In: YES 
user_id=133413

Works! The standard configure in 2.2.1 comments out
HAVE_SYS_RESOURCE_H, whereas your new configure file on a
clean tree does not. Am testing compile now, but don't
anticipate a problem - will let you know if one kicks up.

Logged In: YES 
user_id=133413

Yargh! Well, at least it gets to a _different_ problem
before compilation fails:

gcc  -Xlinker -export-dynamic -o python \
                Modules/python.o \
                libpython2.2.a -ldl  -lpthread -lutil   -lm  
case $MAKEFLAGS in \
*-s*) CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3
-Wall -Wstrict-prototypes' ./python -E ./setup.py -q build;; \
*) CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3
-Wall -Wstrict-prototypes' ./python -E ./setup.py build;; \
esac
make: *** [sharedmods] Error 139

Curiously, I believe what I had before was 2.2.1rc ... um, 1
I think. And it compiled fine once the one line in
pyconfig.h was corrected by hand. Is this another bug report
I should submit?

Logged In: YES 
user_id=21627

This is very strange indeed. It does look like a different
bug, so I would like to close this one. I have committed
this change as

configure 1.279.6.6
configure.in 1.288.6.6

Please report the remaining problem as a new bug report. It
would be good if you could analyse it with more detail, e.g.
by invoking ./python ... manually (with the same variables
that make sets); if it still fails, I recommend to run the
newly-built python in gdb, to produce a backtrace.

Logged In: YES 
user_id=133413

Yes, close this one. Not sure how to analyze this:

# ./python -E ./setup.py build
Segmentation fault (core dumped)

Never have learned the tools for analyzing the dumped core. 

Even just ./python dumps core. My current kernel is
2.4.19-pre9-ac3 - updated since this bug report was
submitted - if that can be pertinent.

Logged In: YES 
user_id=133413

Okay, this probably shows something. I add it here in case
you have a comment on how to submit the bug. But if you
don't, I'll just put in a report on a "dumps core" bug with
this included:

gdb ./python ./core
GNU gdb 4.17.0.11 with Linux support
...
This GDB was configured as "i386-redhat-linux"...
Core was generated by `./python'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libdl.so.2...done.
Reading symbols from /lib/libpthread.so.0...done.
Reading symbols from /lib/libutil.so.1...done.
Reading symbols from /lib/libm.so.6...done.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /lib/ld-linux.so.2...done.
#0  0x8075732 in eval_frame (f=0x8124f94) at Python/ceval.c:1310
1310                            Py_DECREF(u);

Logged In: YES 
user_id=21627

Type 'bt' at the gdb prompt to get a backtrace. In the
specific case, it is also helpful to type 'print u' to get
the value of u at the time of the crash.

Closing this report again.

Logged In: YES 
user_id=226443

This can be fixed by a rearrangement of the conditional 
preprocessor statements at around line 1236 of 
Modules/posixmodule.c as indicated by a patch file I'm going 
to try and attach.

Logged In: YES 
user_id=226443

Right. Since it wasn't obvious how I should attach the file, 
take a look at patch #563954 for details of how I fixed the 
problem. Note that this patch only prevents the compiler 
error - it has *not* been tested at all.

It would be interesting to know why the conditional 
statements were nested, as that was the reason why the 
identifier in question could not be found.