Re: Compiling python 2.0

On Fri, Oct 20, 2000 at 06:49:36PM +0100, Michael Hudson wrote:
"Jean-Claude Levieux" <jclevieux@sud2000.com> writes:
I just tried to compile Python 2.0. on BSDI BSD/OS 4.0.1
[ Sorry, missed the original message. Used the Archive to find it, tho ]
Random guess, but you are using a ANSI C compiler, aren't you? Python 2.0 now demands that.
BSDI uses gcc, so that's not the problem. Neither are these three warnings: /usr/include/math.h:177: warning: function declaration isn't a prototype /usr/include/math.h:257: warning: function declaration isn't a prototype /usr/include/wchar.h:17: warning: function declaration isn't a prototype (or any other warnings regarding 'function decl isn't a prototype) They are a result of Python using '-Wstrict-prototypes' by default, if the compiler is gcc. It just means BSDI declares a few functions without specifying argument lists (prototypes) and has nothing to do with Python (other than that Python always defines CFLAGS to contain -Wstrict-prototypes.) There isn't an easy way to get this 'fixed', unfortunately. If you want to quench the warnings, you'll have to edit ./Makefile, Objects/Makefile, Parser/Makefile, Python/Makefile, and ./Modules/Makefile.pre. (Do not edit ./Modules/Makefile directly, because it's overwritten by the 'makesetup' script, which parses the Setup file.) As for the other error, that's really an error :( ../libpython2.0.a(fileobject.o): In function portable_fseek': /usr/home/thomas/Python-2.0/Objects/fileobject.c:274: undefined reference to `TELL64' The problem is that BSDI has an 'off_t' type that is larger than the 'long' type, and Python's configure makes the flawed assumption that this means BSDI supports large files (larger than 2Gb.) However, BSDI doesn't. This bug is even present with BSDI 4.1, and probably more platforms. You can fix this by editing './config.h' after running './configure', and commenting out the HAVE_LARGEFILE_SUPPORT line; changing this: #define HAVE_LARGEFILE_SUPPORT 1 into something like this: /* #define HAVE_LARGEFILE_SUPPORT 1 */ (You can just remove the line as well.) The downside of both these 'hacks' (excuse me, 'hotfixes'), is that you'll have to reedit the files again after running configure again (or something that runs configure, like 'config.status'.) I see a total of three bugs here: Python adds -Wstrict-prototypes even though it can generate a lot of warnings that aren't related to Python; there is no way to override the CFLAGS variable (you can pass it to configure, and it uses it at first, but then just overwrites it); and mis-detecting large file support. I can't decide which of the last two is the biggest bug :-) I would write a patch for the lot of 'm, but I'm in the middle of getting ready to head to London for the Apache conference (any other Pythonistas going ? :) and Have I Got News For You is about to start on BBC1. If you don't do it, Jean-Claude, I'll submit bugreports on these when I'm back, next Thursday. (Oh, another hint: *disable threads* when compiling Python for BSDI 4.0.1. You can leave them on for 4.1, but 4.0.1 has very broken threads, and it will cause lots of problems in the signal module if you leave them on. You can disable them by using '--with-threads=no' -- this is also listed in the README, by the way. And note that BSDI 4.1 only has the large file support problem, none of the others, and I strongly suggest upgrading for other reasons as well.) Python-dev: CC'd because this is material for a bugfix-release. There are likely to be other platforms hit by the large filesupport misdetection. Don't think this is enough to warrant a bugfix release (it's not *that* brownbaggy) but it should definately go in if there is one ;P If I or someone else didn't fix it by the time a bugfix release is considered, please hit me. I also appologize for not properly testing Python 2.0 on BSDI 4.0.1 or 4.1... We still have those machines, but we are using less and less of them. Out of sight, out of mind, and I'm happier using FreeBSD and Linux :) BSDI-isn't-all-bad--it's-just-that-by-now-Linux-and-FreeBSD-have-all- -those-good-sides-too-ly y'rs, -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

On Fri, Oct 20, 2000 at 10:21:18PM +0200, Thomas Wouters wrote:
This one isthe saem problem that showed up for NetBSD1.4.2 and OpenBSD (I see a pattern) http://sourceforge.net/bugs/?func=detailbug&bug_id=112289&group_id=5470 It was fixed by adding a hack in fileobject.c to *define* TELL64. http://sourceforge.net/patch/index.php?func=detailpatch&patch_id=101558&group_id=5470 For the quickfix, the same hack could be used for BSDI. As you suggest Thomas, the proper fix is to patch configure.in such that it does not report that these system support largefiles. I don't have the time to do this right away, nor do I have one of these boxes on which to test it. I can try to make a patch though. We don't you file a bug and assign it to me. Trent -- Trent Mick TrentM@ActiveState.com

On Fri, Oct 20, 2000 at 10:21:18PM +0200, Thomas Wouters wrote:
This one isthe saem problem that showed up for NetBSD1.4.2 and OpenBSD (I see a pattern) http://sourceforge.net/bugs/?func=detailbug&bug_id=112289&group_id=5470 It was fixed by adding a hack in fileobject.c to *define* TELL64. http://sourceforge.net/patch/index.php?func=detailpatch&patch_id=101558&group_id=5470 For the quickfix, the same hack could be used for BSDI. As you suggest Thomas, the proper fix is to patch configure.in such that it does not report that these system support largefiles. I don't have the time to do this right away, nor do I have one of these boxes on which to test it. I can try to make a patch though. We don't you file a bug and assign it to me. Trent -- Trent Mick TrentM@ActiveState.com
participants (2)
-
Thomas Wouters
-
Trent Mick