Issue535545
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2002-03-27 02:26 by whit, last changed 2022-04-10 16:05 by admin. This issue is now closed.
Files | ||||
---|---|---|---|---|
File name | Uploaded | Description | Edit | |
resource.h | whit, 2002-03-27 19:17 | resource.h | ||
stderr.bz2 | whit, 2002-03-28 13:13 | stderr + posixmodule.i | ||
posixmodule.i.bz2 | whit, 2002-03-28 16:02 | posixmodule.i w/ -dD | ||
config.log | whit, 2002-03-28 16:56 | |||
conf.txt | nobody, 2002-03-29 15:56 | |||
configure.gz | loewis, 2002-06-02 15:13 | Modified configure for 2.2.1 |
Messages (38) | |||
---|---|---|---|
msg10020 - (view) | Author: Whit Blauvelt (whit) | Date: 2002-03-27 02:26 | |
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. |
|||
msg10021 - (view) | Author: Martin v. Löwis (loewis) * ![]() |
Date: 2002-03-27 12:21 | |
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? |
|||
msg10022 - (view) | Author: Whit Blauvelt (whit) | Date: 2002-03-27 15:33 | |
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. |
|||
msg10023 - (view) | Author: Martin v. Löwis (loewis) * ![]() |
Date: 2002-03-27 16:34 | |
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. |
|||
msg10024 - (view) | Author: Whit Blauvelt (whit) | Date: 2002-03-27 19:17 | |
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.... |
|||
msg10025 - (view) | Author: Martin v. Löwis (loewis) * ![]() |
Date: 2002-03-28 00:06 | |
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. |
|||
msg10026 - (view) | Author: Whit Blauvelt (whit) | Date: 2002-03-28 00:35 | |
Logged In: YES user_id=133413 Attached is the end of the stderr output and posixmodule.i (combined in 1 file) |
|||
msg10027 - (view) | Author: Martin v. Löwis (loewis) * ![]() |
Date: 2002-03-28 10:17 | |
Logged In: YES user_id=21627 Unfortunately, it is not attached; please check the checkbox. |
|||
msg10028 - (view) | Author: Whit Blauvelt (whit) | Date: 2002-03-28 13:10 | |
Logged In: YES user_id=133413 Honest, it was checked. But here we go (again)... |
|||
msg10029 - (view) | Author: Whit Blauvelt (whit) | Date: 2002-03-28 13:13 | |
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 |
|||
msg10030 - (view) | Author: Martin v. Löwis (loewis) * ![]() |
Date: 2002-03-28 15:38 | |
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. |
|||
msg10031 - (view) | Author: Whit Blauvelt (whit) | Date: 2002-03-28 16:02 | |
Logged In: YES user_id=133413 Here it is. |
|||
msg10032 - (view) | Author: Martin v. Löwis (loewis) * ![]() |
Date: 2002-03-28 16:42 | |
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? |
|||
msg10033 - (view) | Author: Whit Blauvelt (whit) | Date: 2002-03-28 16:56 | |
Logged In: YES user_id=133413 Right, HAVE_SYS_RESOURCE_H is commented out. config.log attached. |
|||
msg10034 - (view) | Author: Whit Blauvelt (whit) | Date: 2002-03-28 17:20 | |
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? |
|||
msg10035 - (view) | Author: Martin v. Löwis (loewis) * ![]() |
Date: 2002-03-28 21:08 | |
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. |
|||
msg10036 - (view) | Author: Whit Blauvelt (whit) | Date: 2002-03-28 22:43 | |
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 |
|||
msg10037 - (view) | Author: Whit Blauvelt (whit) | Date: 2002-03-28 23:03 | |
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 |
|||
msg10038 - (view) | Author: Whit Blauvelt (whit) | Date: 2002-03-29 04:33 | |
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. |
|||
msg10039 - (view) | Author: Martin v. Löwis (loewis) * ![]() |
Date: 2002-03-29 15:58 | |
Logged In: YES user_id=21627 Please try the attached conf.txt with an otherwise unmodified system, and report whether it solves the problem. |
|||
msg10040 - (view) | Author: Whit Blauvelt (whit) | Date: 2002-03-29 16:30 | |
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> |
|||
msg10041 - (view) | Author: Martin v. Löwis (loewis) * ![]() |
Date: 2002-03-29 16:35 | |
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. |
|||
msg10042 - (view) | Author: Whit Blauvelt (whit) | Date: 2002-03-29 17:12 | |
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. |
|||
msg10043 - (view) | Author: Michael Hudson (mwh) ![]() |
Date: 2002-03-31 20:21 | |
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. |
|||
msg10044 - (view) | Author: Martin v. Löwis (loewis) * ![]() |
Date: 2002-04-02 08:44 | |
Logged In: YES user_id=21627 For 2.2.1, no action is needed - this is a system configuration problem. |
|||
msg10045 - (view) | Author: Martin v. Löwis (loewis) * ![]() |
Date: 2002-06-02 12:26 | |
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. |
|||
msg10046 - (view) | Author: Whit Blauvelt (whit) | Date: 2002-06-02 13:05 | |
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. |
|||
msg10047 - (view) | Author: Martin v. Löwis (loewis) * ![]() |
Date: 2002-06-02 13:19 | |
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. |
|||
msg10048 - (view) | Author: Whit Blauvelt (whit) | Date: 2002-06-02 14:18 | |
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? |
|||
msg10049 - (view) | Author: Martin v. Löwis (loewis) * ![]() |
Date: 2002-06-02 15:12 | |
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. |
|||
msg10050 - (view) | Author: Whit Blauvelt (whit) | Date: 2002-06-02 16:53 | |
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. |
|||
msg10051 - (view) | Author: Whit Blauvelt (whit) | Date: 2002-06-02 17:06 | |
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? |
|||
msg10052 - (view) | Author: Martin v. Löwis (loewis) * ![]() |
Date: 2002-06-02 17:37 | |
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. |
|||
msg10053 - (view) | Author: Whit Blauvelt (whit) | Date: 2002-06-02 17:47 | |
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. |
|||
msg10054 - (view) | Author: Whit Blauvelt (whit) | Date: 2002-06-02 17:51 | |
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); |
|||
msg10055 - (view) | Author: Martin v. Löwis (loewis) * ![]() |
Date: 2002-06-02 17:57 | |
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. |
|||
msg10056 - (view) | Author: Paul Boddie (pboddie) | Date: 2002-06-03 16:49 | |
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. |
|||
msg10057 - (view) | Author: Paul Boddie (pboddie) | Date: 2002-06-03 16:56 | |
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. |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-10 16:05:09 | admin | set | github: 36339 |
2002-03-27 02:26:25 | whit | create |