This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: make _ctypes work with non-gcc compilers
Type: enhancement Stage:
Components: Versions: Python 3.3, Python 3.4
process
Status: languishing Resolution:
Dependencies: Superseder:
Assigned To: theller Nosy List: BreamoreBoy, gregcouch, loewis, mmueller, theller, trent
Priority: normal Keywords:

Created on 2007-11-29 00:52 by gregcouch, last changed 2022-04-11 14:56 by admin.

Files
File name Uploaded Description Edit
_ctypes.diffs gregcouch, 2007-11-29 00:52
Messages (6)
msg57924 - (view) Author: Greg Couch (gregcouch) Date: 2007-11-29 00:52
To get _ctypes to sucessfully compile with native UNIX compilers (i.e.,
not gcc), several modifications need to be made: (1) use the equivalent
of the Py_GCC_ATTRIBUTE macro for __attribute__ (in ffi.h), (2) include
 <ffi_common.h> in callproc.c to conditionally include <alloca.h>, and
(3) modify distutils to know something about assembly language files.

The attached patch is a starting point for the proper patch.  It fixes
bugs (1) and (2), but I was unable to figure out the last tweek to get
distutils to work with gcc and native compilers.

The problem with _ctypes comes from the use of gcc's libffi.  And libffi
 uses assembly language source files for the various supported platforms
and distutils blindly compiles the .S files.  Native UNIX compilers want
a .s suffix and if the files are renamed, distutils skips the file.  I
tried modifying distutils to compile .s files and give the '-x
assembler-with-cpp' flag to gcc so gcc would still work, but the right
tweek evaded me.  So I'm hoping someone can take this and turn it into
something better or make helpful suggestions (other than switching to gcc!).
msg57926 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2007-11-29 05:38
Can you please be specific what compilers and systems you are talking
about? I doubt your statements hold for *all* native UNIX compilers. In
particular, .s files should be compiled with as, not cc, on the UNIX
systems I'm familiar with, but that won't involve the C preprocessor.
msg57951 - (view) Author: Greg Couch (gregcouch) Date: 2007-11-29 19:46
The modications work on Tru64 and IRIX.  cc has understood .s suffixes
for a long time.  You use cc instead of as because it knows how to run
the C preprocessor (often /lib/cpp, but not on all systems).

Looking at the Solaris cc manual page (via google), I see that its cc
has the same .S and .s distinction that gcc has, so my patch will not
work with Solaris either.  IRIX has a separate issue in that it has
libffi support for n32 binaries, but doesn't have the ffi_closure
support, so while libffi compiles, _ctypes still fails  to compile (same
would be true if gcc were used).
msg173276 - (view) Author: Trent Nelson (trent) * (Python committer) Date: 2012-10-18 15:04
Hi Greg,

    I realize it's been a good five years since you first raised this
    issue, but I was wondering if you ever ended up making any progress
    with it?

    In trying to get Python working on Snakebite UNIX boxes with vendor
    CCs, I'm running into all sorts of issues.
msg173279 - (view) Author: Greg Couch (gregcouch) Date: 2012-10-18 15:48
On Thu, 18 Oct 2012, Trent Nelson wrote:

> Trent Nelson added the comment:
>
> Hi Greg,
>
>    I realize it's been a good five years since you first raised this
>    issue, but I was wondering if you ever ended up making any progress
>    with it?
>
>    In trying to get Python working on Snakebite UNIX boxes with vendor
>    CCs, I'm running into all sorts of issues.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue1516>
> _______________________________________

Hi Trent,

Sorry to say I don't have any more insight on how to get libffi working on 
more platforms.  Lucking ctypes isn't used in the Python core, so it's 
not required to get Python working.  I'm using supported compilers on all 
platforms now.

     Good luck,

     Greg
msg214542 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2014-03-23 03:21
Given msg173279 from Greg Couch "I'm using supported compilers on all 
platforms now." can we close this issue or does Trent Nelson still have problems?
History
Date User Action Args
2022-04-11 14:56:28adminsetgithub: 45857
2014-03-23 03:21:19BreamoreBoysetnosy: + BreamoreBoy
messages: + msg214542
2013-10-25 07:57:50christian.heimessetstatus: open -> languishing
versions: + Python 3.3, Python 3.4, - Python 3.2
2012-10-18 15:48:38gregcouchsetmessages: + msg173279
2012-10-18 15:04:30trentsetmessages: + msg173276
2012-10-18 12:46:16trentsetnosy: + trent
2010-06-10 23:43:20belopolskysettype: enhancement
versions: + Python 3.2, - Python 2.6
2008-09-09 08:38:51mmuellersetnosy: + mmueller
2008-03-18 00:10:09jafosetpriority: normal
2007-11-29 19:46:17gregcouchsetmessages: + msg57951
2007-11-29 05:38:48loewissetassignee: theller
messages: + msg57926
nosy: + loewis, theller
2007-11-29 00:52:59gregcouchcreate