Build bugs in Python 2.2.1?

Mahrt, Dallas dallasm at
Tue Aug 20 23:54:34 CEST 2002

One aspect of the build process that has been avoided in this discussion is
the problems 
that the process causes for cross-compiling. Because the
build process 
depends on the host and build targets to be the same, cross-compilation
cannot happened with 
a './configure <opts>; make; make install'. This is because the built
interpreter is used to 
execute the program. While I have devised a painful solution for
this problem, 
several other problems occur during the module build process. Among them are

1) Cannot create shared library modules: Modules that are compiled as shared
are rejected since they cannot be loaded on this system.

2) Cannot compile the pure-Python modules since you cannot use the

3) While most files are installed using GNU's libtools, directories are
created using a 
standard makedir. This complicates systems where the install program
reroutes an install 
path to a staging are in order to create a ramdisk. 

Example. Calling '$(INSTALL) /usr/lib/python2.2/' installs the
program in /home/user/dev/project/staging/usr/lib/python2.2/

These are simply the problems I have encountered thus far. I am hacking some
quick fixes together 
to solve this problem but would welcome discussion on more permanent ways
(via patches) that I could 
Modify this process to better enable cross-compilation.

Dallas S. Mahrt 

> -----Original Message-----
> From: loewis at 
> [mailto:loewis at] 
> Sent: Monday, August 12, 2002 3:30 AM
> To: python-list at
> Subject: Re: Build bugs in Python 2.2.1?
> DIG <dig.list at> writes:
> [using autoconf for building modules]
> > > Please understand that this option has been explicitly 
> considered, 
> > > and has been rejected in favour of a distutils-based 
> build approach.
> >
> > It would be much more understandable, if you explicitly told us why 
> > this option has been considered, but rejected ...
> distutils and autoconf are largely overlapping for building 
> extension modules. distutils has the advantage of
> a) being able to record the dependencies between files, and
> b) requiring only Python and the C compiler to build extensions.
> I believe people also think that
> c) Python code is better readable and maintainable than autoconf
>    source code, and
> d) for the things that you need to determine when building extension
>    modules, autoconf is no big help.
> Furthermore,
> e) there is no inherent magic in autoconf that could not be provided
>    in a Python library (i.e. distutils).
> HTH,
> Martin
> -- 

More information about the Python-list mailing list