Build bugs in Python 2.2.1?
Lars Kellogg-Stedman
lars_news at larsshack.org
Fri Aug 9 11:22:22 EDT 2002
> Since the build process is complex, you should at least mention the platform
> you are trying to build for.
> [ allegedly helpful message ]
Steve,
I'm sure you didn't mean it, but your message sounded a bit
condescending. You may not have had much experience building python for
installation outside of "traditional" locations such as /usr or
/usr/local, but I assure you that the problems I've encountered do not
appear to be platform specific.
The problems occur with all the platforms I have built python on. This
includes Solaris (2.[78]) and RedHat Linux (7.[0123]). There does not
appear to be a mechanism in place for the top level Makefile to
communicate compiler flag settings to the module build process. I've
looked through some of the distutils code, and there's a routine called
read_setup_file() that looks like it may provide for setting linker
flags, but it doesn't appear to be called from anywhere. And in fact,
if you examine build_ext.py, you find:
# XXX and if we support CFLAGS, why not CC (compiler
# executable), CPPFLAGS (pre-processor options), and LDFLAGS
# (linker options) too?
# XXX should we use shlex to properly parse CFLAGS?
So setting environment variables isn't an option either.
The bugs are easy to reproduce:
mkdir foo
cd foo
env CC=gcc \
LDFLAGS='-L/my/path/lib -Wl,-rpath,/my/path/lib' \
CPPFLAGS='-I/my/path/include' \
../Python-2.1.1/configure --prefix=/my/path/python-2.1.1
Check the Makefile. See that the LDFLAGS macro is set. Run 'make'.
Watch python proper get built with the proper linker options. Watch the
modules build without these options.
If you watch closely, you also note that CPPOPTIONS in the environment
simply don't get substituted into the top level Makefile, period.
That's because Makefile.pre.in includes the following:
CPPFLAGS= -I. -I$(srcdir)/Include $(DEFS)
Notice that there's no @CPPFLAGS@ here, so even the interpreter build
process may not work as expected.
The second problem -- in which setup.py arbitrarily adds
/usr/local/{lib,include} to the search path -- can be verified by code
inspection.
Cheers,
-- Lars
More information about the Python-list
mailing list