RetroSearch Browse

Mon May 19 10:05:09 CEST 2008 · https://mail.python.org/pipermail/python-dev/2008-May/079557.html

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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2008-May/079557.html below:

[Python-Dev] Addition of "pyprocessing" module to standard lib.