[Python-Dev] Addition of "pyprocessing" module to standard lib.
Ulrich Berning
ulrich.berning at denviso.de
Mon May 19 10:05:09 CEST 2008
Nick Coghlan wrote:
> Ulrich Berning wrote:
>
>> More and more people tend to say "Runs on Un*x" when they really mean
>> "Tested on Linux". Un*x is not Linux.
>
>
> Hmm, perhaps that would be why there are Solaris, FreeBSD and Tru64
> machines amongst the main Python buildbots, to go along with the
> assorted OS X, Windows and Linux boxes - and as far as I know
> test_ctypes runs quite happily on all of them.
>
> On the specific problems with AIX, HP-UX and ctypes, was it ctypes
> itself that was failing to build, or the underlying libffi?
>
> Cheers,
> Nick.
>
On HP-UX-11.00, HP ANSI C++ B3910B A.03.73, Python-2.5.2, I get
configure: error: "libffi has not been ported to hppa2.0w-hp-hpux11.00."
On AIX-4.3.3, C for AIX Compiler Version 6, Python-2.5.2, I get
"build/temp.aix-4.3-2.5/libffi/include/ffi.h", line 123.4: 1506-205
(S) #error "no 64-bit data type supported"
On Solaris-10/x86, Sun C 5.8 Patch 121016-07 2007/10/03, Python-2.5.2, I get
"build/temp.solaris-2.10-i86pc-2.5/libffi/include/ffitarget.h", line
64: undefined symbol: FFI_DEFAULT_ABI
On Solaris-8/sparc, Sun C 5.8 2005/10/13, Python-2.5.2, I get
"build/temp.solaris-2.8-sun4u-2.5/libffi/include/ffi.h", line 225:
syntax error before or at: __attribute__
On IRIX-6.5, gcc-3.4.4, Python-2.5.2, ffi_closure is undefined, because
only the old O32 binary format is supported, not the new N32/N64 format.
I'm trying to use the vendor specific compilers whenever possible,
because using gcc puts in additional dependencies (libgcc), I want to
avoid, and even if I could live with these dependencies, it's not easy
to get/build the 'right' gcc version, if your software also depends on
other big packages like Qt and PyQt.
I'm not using these platforms for my own pleasure (in fact, I would be
happy if these platforms would disappear from the market), but as long
as our customers use these platforms, we want to promise our software
runs on those platforms.
I have no problem with the fact that ctypes doesn't build on those
platforms because I don't use it, but if more and more essential
packages depend on ctypes, I'm running into trouble. PyOpenGL is an
example of an extension, that moved completely from C-Source (SWIG
generated) to ctypes usage.
Ulli
More information about the Python-Dev
mailing list