#799 Preprocessor doesn't define target arch. ( __i386__)

[John Nagle]

SWIG's preprocessor, unlike the one in GCC, does not define the target architecture symbols, like "__i386__".
This causes includes of files which use those symbols to fail.

This breaks builds involving "openssl", particularly M2Crypto, Python's interface to OpenSSL.

(Related post by Guido von Rossum, suggesting that
SWIG be dumped from Python builds:
http://www.artima.com/weblogs/viewpost.jsp?thread=95863\)

[David M. Beazley]

Logged In: YES
user_id=7557
Originator: NO

Run SWIG with swig -D__i386__

[John Nagle]

Logged In: YES
user_id=5571
Originator: YES

Status: "Developer in denial".

As SWIG undertakes to emulate CPP, it should do so correctly.

[William Fulton]

Logged In: YES
user_id=242951
Originator: NO

The overriding goal of SWIG is to generate platform neutral code. If it were to secretly define platform specific macros this would not be possible. Besides since when is __386__ in any known standard? How is SWIG meant ever going to be aware of every known system's preprocessor definitions for all known compilers? Many of these are turned on with compiler specific commandline options, some undocumented. I'm afraid SWIG is doing the right thing here and it is up to the programmer to go out of his/her way to make SWIG generate platform specific code.

[Josh Cherry]

Logged In: YES
user_id=957678
Originator: NO

Does the C or C++ standard say that __i386__ should be defined? Is it even common for compilers to do so, or is this fairly gcc-specific? You can't expect SWIG to know what compiler you intend to use or what it defines for you.

That said, there is the practical question of how to handle this sort of thing. Running gcc -E -dD on an empty file produces a dump of #define's (N.B.: they're affected by gcc options such as -O). You could dump these to a file and %include it in your SWIG interface file. That will get you things like __GNUC__, which SWIG couldn't possibly give you by itself.