[Python-Dev] Pass possibly imcompatible options to distutil's ccompiler

Lukas Lueg lukas.lueg at googlemail.com
Mon Apr 11 23:41:42 CEST 2011


Hi,

I'm the maintainer of Pyrit (http://pyrit.googlecode.com) and recently
checked in some code that uses the AES-NI intrinsics found in GCC
4.4+. I'm looking for a way how to build the python-extension using
distutils in a sane way and could not get an answer from the
distutils-people about that.

The enable the intrinsics, one must pass '-maes' and '-mpclmul' as
commandline-arguments to gcc, e.g. through extra_compile_args. This is
not always safe to do as previous versions of GCC do not support these
options and cause cc to fail with an error. Such platforms are not
uncommon, e.g. XCode 3.2 on MacOS is shipped with gcc 4.2. I fail to
see how to determine in advance what compiler distutils will use and
what version that compiler has. Therefor I see two options:
- Try to build a small pseudo-extension with the flags enabled, watch
for exceptions and only enable the extra_compile_args on the real
extension if the build succeeds
- Override the build_ext-command with another class and override
build_extension. Try to build the extension and, if a CompilerError is
thrown, remove '-maes' and '-mpclmul' from extra_compile_args. Try
again and re-raise possible CompilerErrors now.

The first option seems rather bogus so I'm currently going with the
second option. After all, this leaves me with the best chance of
enabling the AES-NI-code on compatible machines (no false-negatives
with some kind of auto-detection) and not having people being unable
to compile it at all (false-positives, resulting in final compiler
errors). The downside is that visible error messages are printed to
stderr from the first call to build_ext.build_extension if AES-NI is
actually not supported.

Any other ideas on how to solve this in a better way?


Best regards
Lukas


More information about the Python-Dev mailing list