Does anybody else see this? ... gcc -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:1145: warning: implicit declaration of function `getpriority' ./Modules/posixmodule.c:1145: `PRIO_PROCESS' undeclared (first use in this function) ./Modules/posixmodule.c:1145: (Each undeclared identifier is reported only once ./Modules/posixmodule.c:1145: for each function it appears in.) make: *** [Modules/posixmodule.o] Error 1 I just did a fresh cvs update -A, make distclean, configure, make. This on a RH6.1-ish Linux box, with uname -a: Linux anthem 2.2.18 #21 SMP Mon Jan 8 00:33:29 EST 2001 i686 unknown This bit of code doesn't appear to have changed in a while, so maybe something else in the configure/build process has changed to break this? From ./configure: ... checking for getpriority... yes ... checking for broken nice()... yes -Barry
Based upon Barry's speculation that something might have changed in the configure process I mv'd my config.cache out of the way before configuring (like Barry, after a cvs up -A). I was a bit surprised to see these changes: % diff config.cache.save config.cache | less 185a186 > ac_cv_pthread_system_supported=${ac_cv_pthread_system_supported=no} 190c191 < ac_cv_sizeof_fpos_t=${ac_cv_sizeof_fpos_t=12} --- > ac_cv_sizeof_fpos_t=${ac_cv_sizeof_fpos_t=16} 194c195 < ac_cv_sizeof_off_t=${ac_cv_sizeof_off_t=4} --- > ac_cv_sizeof_off_t=${ac_cv_sizeof_off_t=8} Given that my system hasn't changed in the past couple of days, I wonder why it thought the default size of some of these offsets should change. (New update of configure, perhaps?) Still, I had no problem building on my Mandrake 8.0 system. Skip
Based upon Barry's speculation that something might have changed in the configure process I mv'd my config.cache out of the way before configuring (like Barry, after a cvs up -A). I was a bit surprised to see these changes:
% diff config.cache.save config.cache | less 185a186 > ac_cv_pthread_system_supported=${ac_cv_pthread_system_supported=no} 190c191 < ac_cv_sizeof_fpos_t=${ac_cv_sizeof_fpos_t=12} --- > ac_cv_sizeof_fpos_t=${ac_cv_sizeof_fpos_t=16} 194c195 < ac_cv_sizeof_off_t=${ac_cv_sizeof_off_t=4} --- > ac_cv_sizeof_off_t=${ac_cv_sizeof_off_t=8}
Given that my system hasn't changed in the past couple of days, I wonder why it thought the default size of some of these offsets should change. (New update of configure, perhaps?) Still, I had no problem building on my Mandrake 8.0 system.
It has to do with this NEWS item: - Large file support (LFS) is now automatic when the platform supports it; no more manual configuration tweaks are needed. On Linux, at least, it's possible to have a system whose C library supports large files but whose kernel doesn't; in this case, large file support is still enabled but doesn't do you any good unless you upgrade your kernel or share your Python executable with another system whose kernel has large file support. I believe there's an SF bug report mentioning the same problem that Barry reports. --Guido van Rossum (home page: http://www.python.org/~guido/)
I believe there's an SF bug report mentioning the same problem that Barry reports.
Not only that, but Barry reported fixing it two months ago(!): Date: 2001-07-11 18:10 Sender: bwarsaw Logged In: YES user_id=12800 Ploing! I just reported this same problem to python-dev. Attached is a patch that fixes it for me on my RH6.1-ish Linux box. That from http://sf.net/tracker/?group_id=5470&atid=105470&func=detail&aid=440522 It was reported (and closed) again in http://sf.net/tracker/?group_id=5470&atid=105470&func=detail&aid=443042
"TP" == Tim Peters <tim.one@home.com> writes:
>> I believe there's an SF bug report mentioning the same problem >> that Barry reports. TP> Not only that, but Barry reported fixing it two months ago(!): Oh jeez. | Date: 2001-07-11 18:10 | Sender: bwarsaw | Logged In: YES | user_id=12800 | Ploing! I just reported this same problem to python-dev. | Attached is a patch that fixes it for me on my RH6.1-ish | Linux box. Yeah, but posixmodule.c has this bit in it: #ifdef HAVE_NICE #if defined(HAVE_BROKEN_NICE) && defined(HAVE_SYS_RESOURCE_H) #if defined(HAVE_GETPRIORITY) && !defined(PRIO_PROCESS) #include <sys/resource.h> #endif #endif So why isn't sys/resource.h getting included? -Barry
"BAW" == Barry A Warsaw <barry@zope.com> writes:
BAW> Yeah, but posixmodule.c has this bit in it: | #ifdef HAVE_NICE | #if defined(HAVE_BROKEN_NICE) && defined(HAVE_SYS_RESOURCE_H) | #if defined(HAVE_GETPRIORITY) && !defined(PRIO_PROCESS) | #include <sys/resource.h> | #endif | #endif BAW> So why isn't sys/resource.h getting included? ...because configure isn't finding it: checking for sys/resource.h... no so HAVE_SYS_RESOURCE_H isn't getting defined in pyconfig.h. It's there in /usr/include though: % ls -l /usr/include/sys/resource.h -rw-r--r-- 1 root root 3185 Sep 20 1999 /usr/include/sys/resource.h Strange. More investigation tomorrow. -Barry
"BAW" == Barry A Warsaw <barry@zope.com> writes:
BAW> So why isn't sys/resource.h getting included? BAW> ...because configure isn't finding it: BAW> checking for sys/resource.h... no Closer... /usr/include/sys/resource.h #include's /usr/include/bits/resource.h which in turn #include's /usr/include/asm/resource.h. asm/resource.h has this: /* * SuS says limits have to be unsigned. * Which makes a ton more sense anyway. */ #define RLIM_INFINITY (~0UL) which is not protected by #defines. bits/resource.h has this: /* 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 which itself doesn't #undef RLIM_INFINITY or otherwise protect itself. So when configure runs we get a bunch of redefined warnings. Compiling just this simple file: -------------------- snip snip -------------------- #include <sys/resource.h> int main() { return 0; } -------------------- snip snip -------------------- Gives us: -------------------- snip snip -------------------- In file included from /usr/include/sys/resource.h:25, from main.c:1: /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 -------------------- snip snip -------------------- which must configure configure into thinking resource.h isn't available. Looks like a glibc update might be in order <shudder>: http://sources.redhat.com/ml/bug-glibc/2000-02/msg00026.html http://sources.redhat.com/ml/bug-glibc/2000-02/msg00027.html http://sources.redhat.com/ml/bug-glibc/2000-10/msg00078.html http://sources.redhat.com/ml/bug-glibc/2000-10/msg00084.html The odd bit is that I'm still running the 2.2.18 kernel, although glibc is fairly old. % rpm -q glibc glibc-2.1.2-11 Wonder if I can find glibc-2.1.3 somewhere. then-again-i've-been-looking-for-a-good-excuse-to-install-mandrake-8.0-ly y'rs, -Barry
Guido informs me that there was a similar bug report for 2.2a1, which Thomas closed. It's 443042, which I'm re-opening. Thomas, feel free to assign it to me for further investigation. -Barry
participants (4)
-
barry＠zope.com -
Guido van Rossum -
Skip Montanaro -
Tim Peters