Re: Python ctypes + Intel compilers interop problem

[Timothy Wall <twalljava at dev dot java dot net>]

On May 20, 2009, at 4:32 AM, Andrew Haley wrote:

> Jennings, Jared L CTR USAF AFMC 46 SK/CCI wrote:
> > I failed to compile Python 2.6 using Intel compilers (version 9.1). I
> > reported the issue to the Python folk: http://bugs.python.org/issue4130
> > (q.v.). After that I found that the file I was talking about was  
> > part of
> > libffi. So I subscribed to this list and lurked some. Now I'm not  
> > sure
> > who wants to know about the problem.
> >
> > Does Python get its libffi from sourceware? Does libffi intend to be
> > compilable using any C compiler?
>
> Not as far as I know.  There would be some work getting some of the
> low-level parts working with other compilers.

My initial port to win64 used the free MS cross-compiler.  While there  
are existing wrappers that are supposed to adapt to non-gcc compilers,  
ended up writing my own wrapper script around the compiler/linker.  I  
tried configuring with just CC=cl.exe for a while but ended up  
pointing to a custom script instead.

> > I can't get to the machine where I found the issue anymore, so I  
> > can't
> > replicate it; but it appears that __INTEL_COMPILER is defined when  
> > using
> > icc, and icc defines the __m128 type instead of the __int128_t  
> > type. I
> > think the only use of __int128_t is in ffi64.c, in the register_args
> > struct.
>
> There's also the AT&T assembler syntax to consider, and some GNU  
> extended
> asm in some ports.  But I don't suppose anyone would object terribly  
> to
> a few #ifdefs that would make libffi build with other compilers.

My win64.S has both syntaxes; kind of a pain to maintain, but it's a  
relatively small amount of code.  The changes to the rest of the code  
solely to accommodate the compiler were fairly minimal (probably  
around 10-20 lines of code).