Build bugs in Python 2.2.1?

Lars Kellogg-Stedman lars_news at larsshack.org
Fri Aug 9 17:22:22 CEST 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