The ctypes test failed since the _ctypes module did not compile for 32-
bit Python 2.6a2 on Solaris 10 (Opteron) built with the SUN C compiler.

...
cc -KPIC -xtarget=native -DNDEBUG -xO5 -I. -I/.../tools/Python-
2.6a2/./Include -Ibuild/temp.solaris-2.10-i86pc-2.6/libffi/include -
Ibuild/temp.solaris-2.10-i86pc-2.6/libffi -I/.../tools/Python-
2.6a2/Modules/_ctypes/libffi/src -I. -IInclude -I./Include -
I/.../tools/Python-2.6a2/Include -I/.../tools/Python-2.6a2 -c 
.../tools/Python-2.6a2/Modules/_ctypes/_ctypes.c -o build/temp.solaris-
2.10-i86pc-2.6/.../tools/Python-2.6a2/Modules/_ctypes/_ctypes.o
"build/temp.solaris-2.10-i86pc-2.6/libffi/include/ffitarget.h", line 67: 
undefined symbol: FFI_DEFAULT_ABI
"build/temp.solaris-2.10-i86pc-2.6/libffi/include/ffitarget.h", line 68: 
non-constant enumerator value
"build/temp.solaris-2.10-i86pc-2.6/libffi/include/ffi.h", line 255: 
syntax error before or at: __attribute__
"build/temp.solaris-2.10-i86pc-2.6/libffi/include/ffi.h", line 255: 
warning: old-style declaration or incorrect type for: __attribute__
"build/temp.solaris-2.10-i86pc-2.6/libffi/include/ffi.h", line 255: 
warning: syntax error:  empty declaration
".../tools/Python-2.6a2/Modules/_ctypes/_ctypes.c", line 155: cannot 
recover from previous errors
cc: acomp failed for /.../tools/Python-2.6a2/Modules/_ctypes/_ctypes.c
...

Are you interested in working on a patch?

Yes, but the _ctypes module requires gcc, as Thomas Heller mentioned.  The 
only thing which can be done is avoid building the _ctypes module if the 
compiler is not gcc.  I did look at fixing that but have not found the 
proper way to do that.

> Yes, but the _ctypes module requires gcc, as Thomas Heller mentioned.

So the proper fix for that would be to port it to SunPro, of course.

> The 
> only thing which can be done is avoid building the _ctypes module if the 
> compiler is not gcc.

I'm not sure whether that would be much better than the status quo,
though. People would continue to complain that the ctypes module is not
built.

Why do you consider the current behaviour incorrect?

> I did look at fixing that but have not found the 
> proper way to do that.

There are several ways. One is to skip compilation in setup.py, for
which you should then determine whether the compiler is gcc. For
that, you could look at ac_compiler_gnu in configure.in, and
set a variable in Makefile.pre.in if the compiler is GCC. Then,
in setup.py, you could look for that variable as parsed from
the Makefile, and skip _ctypes accordingly.

Alternatively, you could check for __GNUC__ when compiling
ctypes, and make the compiler produce a better-understandable
#error.

Regards,
Martin

For ctypes to compile with the SUN's C compiler, there is quite a bit of 
tricky asm code which needs to be ported (and tested).  Most of that is 
in libffi and that library is only supported with gcc, it seems.  But 
that is not mentioned explicitly anywhere either, see 
<http://sources.redhat.com/libffi/>.

In any case, the _ctypes module does not compile with SUN C in the 
current situation.  And it is not obvious why.  Making that clear with 
some message that ctypes (rather _ctypes) requires gcc would help and 
might be sufficient.

However, leaving the _ctypes module out altogether would be better. Just 
like other modules which have environment-specific dependencies, for 
example _tkinter.  I'll take a look how that is handled.

/Jean

The setup.py module contains method  detect_ctypes on line 1546 which 
handles the ctypes module building and testing.  Would it be OK to not 
do any of that on Solaris, if the compiler is not gcc? 

Also, SUN Studio 12, the latest edition of the SUN C compiler has "... 
increased GCC __asm__ and __attribute__ compatibility ...", see 
<http://blogs.sun.com/tatkar/entry/sunstudio_12_is_released> and 
<http://developers.sun.com/sunstudio/documentation/ss12/whatsnew.html>.  Maybe that one could compile libffi as is, for x86[_64]?

> Would it be OK to not 
> do any of that on Solaris, if the compiler is not gcc? 

That would be fine.

Attached is one attempt to avoid building the _ctypes module if the 
compiler is not gcc: a patch for Python 2.6a2 with just 2 changes for 
setup.py based on the value of config variable CC.

I'm curious:  Why do you insist on using the sun compiler?  Are there
political or technical reasons?

Another thing: in principle it should be possible to build a libffi
shared library with gcc, and use it in a sun-c compiled python build. 
At least this would avoid the need to port assembler code from gcc to sun c.

Python should be configured with './configure --with-systemffi' for that.

I think this is incorrect; CC might also be "gcc -pipe" or
"/usr/local/bin/gcc", or some such, and would still be gcc (perhaps even
/usr/local/bin/cc).

agreed, do not check to see if the string is == 'gcc'.  Instead,
actually execute the CC compiler with a -v flag and test if 'gcc
version' in output.

something like this (but split into a few statements for readability):

if 'gcc version' not in os.popen(sysconfig.get_config_vars().get('CC',
'gcc') + ' -v').read():
  # gcc is required for ctypes

Well, so much for the first attempt.  I'll see what it takes to use 
something else, like ac_compiler_gnu.  Unless Gregory's suggestion 
qualifies.

Also, I am using SUN's compilers on Solaris 10 for 'political' and some 
technical reasons.  And I am building alpha and beta Python releases 
mainly to help Python move forward.

> Well, so much for the first attempt.  I'll see what it takes to use 
> something else, like ac_compiler_gnu.  Unless Gregory's suggestion 
> qualifies.

I would prefer to see the configure test for gcc be recorded and
passed through, over trying to detect gcc from its -v output, yes.
Who knows what other compilers will do when passed the -v option?

Agreed.  In addition, gcc -v writes to stderr and catching the output 
requires redirecting stderr or using os.popen3 or -4.  The latter fail 
since the select module (needed by subprocess) is still missing at that 
time.

Going back to Thomas' comments and before getting into implementation 
details, the best way to address the issue might be the following.

If the compiler is not gcc then config option --with-system-ffi *must* 
be specified (and a libffi library must exist).

If option --with-system-ffi is not specified and if the compiler is not 
gcc, raise an error.

> If option --with-system-ffi is not specified and if the compiler is not 
> gcc, raise an error.

Up to here, it all sounded fine. What do you mean by error? Abort?
That should not happen. Instead, setup.py skips modules if it doesn't
find the proper prerequisites - which here is the pre-existing FFI
implementation.

Instead of  ... raise an error, it should read  ... report the _ctypes 
module as missing, do not run any tests, etc.

Given the title is this still relevant given that Oracle Solaris 11 is closed source?

Can we close this as I cannot see how a test failure against a 6.5 year old alpha build can still be relevant?