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
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
"BAW" == Barry A Warsaw
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
"BAW" == Barry A Warsaw
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
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