[Python-Dev] Building Python cvs w/ gcc 3.1

Barry A. Warsaw barry@zope.com
Thu, 27 Jun 2002 15:13:05 -0400

File this under "you just can't win".

I'm building Python cvs w/gcc 3.1 and I get warnings for every
extension, e.g.:

building 'zlib' extension
gcc -g -Wall -Wstrict-prototypes -fPIC -I. -I/home/barry/projects/python/./Include -I/usr/local/include -I/home/barry/projects/python/Include -I/home/barry/projects/python -c /home/barry/projects/python/Modules/zlibmodule.c -o build/temp.linux-i686-2.3/zlibmodule.o
cc1: warning: changing search order for system directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-system directory
gcc -shared build/temp.linux-i686-2.3/zlibmodule.o -L/usr/local/lib -lz -o build/lib.linux-i686-2.3/zlib.so

The problem is the inclusion of -I/usr/local/include because that's a
directory on gcc's system include path.  Adding such directories can
cause gcc headaches because it likes to treat system include dirs
specially, doing helpful things like fix bugs in vendor's header files
and sticking them in special locations.  -I apparently overrides the
special treatment of system include dirs, so the warnings are gcc's
way of helpfully reminding us not to do that.

Unfortunately, it seems difficult to fix this in a principled way.  I
can't figure out a way to reliably ask gcc what its system include
dirs are.  -v doesn't give you the information.

There's no switch to turn off these warnings.

You could ask cpp ("cpp -v") which does provide output that could be
grep'd for the system include dirs, but that just seems way too
fragile.  Besides, that doesn't play well with distutils because it
only wants to invoke the preprocessor using "gcc -E" and /that/
interprets -v as one of its options.  You could use
"gcc -E -Wp,-v dummyfile.c" but then you'd have to redirect stderr,
capture that output, and grep it.  Blech, blech, blech.

If I comment out the line in setup.py which add /usr/local/include to
self.compiler.include_dirs, it takes care of the problem, but that
might break other builds, so I'm loathe to do that.

The other option is to ignore the warnings since I don't think gcc 3.1
(3.x?) is distributed as the default compiler for very many distros
yet.  OTOH, it /will/ at some point and then it will be a PITA for
support <wink>.  OTTH, from some quick googling, I gather that this
warning is somewhat controversial inside the gcc community, and other
projects have dealt with it in heavyhanded ways (just don't
-I/usr/local/include), so if we ignore it long enough, the problem
might just go away.

Sigh, I'm done with this for now, but wanted to get it into the
archives for future reference.