Compiling python 2.0

Thomas Wouters thomas at xs4all.net
Fri Oct 20 16:21:18 EDT 2000


On Fri, Oct 20, 2000 at 06:49:36PM +0100, Michael Hudson wrote:
> "Jean-Claude Levieux" <jclevieux at 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 at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!




More information about the Python-list mailing list