Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

make _ctypes work with non-gcc compilers #45857

Closed
gregcouch mannequin opened this issue Nov 29, 2007 · 7 comments
Closed

make _ctypes work with non-gcc compilers #45857

gregcouch mannequin opened this issue Nov 29, 2007 · 7 comments
Assignees
@theller
Labels
type-feature A feature request or enhancement

Comments

@gregcouch
Copy link
Mannequin

gregcouch mannequin commented Nov 29, 2007

BPO 1516
Nosy @loewis, @theller, @tpn
Files
  • _ctypes.diffs
    		•

    Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = 'https://github.com/theller'
closed_at = None
created_at = <Date 2007-11-29.00:52:59.436>
labels = ['type-feature']
title = 'make _ctypes work with non-gcc compilers'
updated_at = <Date 2014-03-23.03:21:19.979>
user = 'https://bugs.python.org/gregcouch'

    bugs.python.org fields:

    activity = <Date 2014-03-23.03:21:19.979>
actor = 'BreamoreBoy'
assignee = 'theller'
closed = False
closed_date = None
closer = None
components = []
creation = <Date 2007-11-29.00:52:59.436>
creator = 'gregcouch'
dependencies = []
files = ['8819']
hgrepos = []
issue_num = 1516
keywords = []
message_count = 6.0
messages = ['57924', '57926', '57951', '173276', '173279', '214542']
nosy_count = 6.0
nosy_names = ['loewis', 'theller', 'gregcouch', 'trent', 'mmueller', 'BreamoreBoy']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'languishing'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue1516'
versions = ['Python 3.3', 'Python 3.4']
    @gregcouch
    Copy link
    Mannequin Author

    gregcouch mannequin commented Nov 29, 2007

    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!).

    @loewis
    Copy link
    Mannequin

    loewis mannequin commented Nov 29, 2007

    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.

    @loewis loewis mannequin assigned theller Nov 29, 2007
    @gregcouch
    Copy link
    Mannequin Author

    gregcouch mannequin commented Nov 29, 2007

    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).

    @abalkin abalkin added the type-feature A feature request or enhancement label Jun 10, 2010
    @tpn
    Copy link
    Member

    tpn commented Oct 18, 2012

    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.

    @gregcouch
    Copy link
    Mannequin Author

    gregcouch mannequin commented Oct 18, 2012

    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

    @tiran tiran added the stale Stale PR or inactive for long period of time. label Oct 25, 2013
    @BreamoreBoy
    Copy link
    Mannequin

    BreamoreBoy mannequin commented Mar 23, 2014

    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?

    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    @kumaraditya303
    Copy link
    Contributor

    Closing as it is fairly outdated now and OP is successfully able to use it on supported platforms.

    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Assignees

    @theller theller

    Labels
    type-feature A feature request or enhancement
    Projects
    None yet
    Milestone
    No milestone
    Development

    No branches or pull requests
    5 participants
    @tiran @abalkin @tpn @theller @kumaraditya303