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.

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

Don't use AC_RUN_IFELSE to determine float endian #78766

Closed
rossburton mannequin opened this issue Sep 5, 2018 · 4 comments
Closed

Don't use AC_RUN_IFELSE to determine float endian #78766

rossburton mannequin opened this issue Sep 5, 2018 · 4 comments
Labels
3.8 only security fixes build The build process and cross-build

Comments

@rossburton
Copy link
Mannequin

rossburton mannequin commented Sep 5, 2018

BPO 34585
Nosy @tim-one, @mdickinson, @benjaminp, @rossburton, @yan12125
PRs
  • [RFC] bpo-34585: Don't do runtime test to get float byte order #9085
  • Files
  • 0001-Don-t-do-runtime-test-to-get-float-byte-order.patch
  • 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 = None
    closed_at = <Date 2018-09-19.06:25:56.225>
    created_at = <Date 2018-09-05.10:57:22.362>
    labels = ['build', '3.8']
    title = "Don't use AC_RUN_IFELSE to determine float endian"
    updated_at = <Date 2018-09-19.06:49:08.815>
    user = 'https://github.com/rossburton'

    bugs.python.org fields:

    activity = <Date 2018-09-19.06:49:08.815>
    actor = 'benjamin.peterson'
    assignee = 'none'
    closed = True
    closed_date = <Date 2018-09-19.06:25:56.225>
    closer = 'benjamin.peterson'
    components = ['Build']
    creation = <Date 2018-09-05.10:57:22.362>
    creator = 'rossburton'
    dependencies = []
    files = ['47788']
    hgrepos = []
    issue_num = 34585
    keywords = ['patch']
    message_count = 3.0
    messages = ['324627', '325705', '325708']
    nosy_count = 5.0
    nosy_names = ['tim.peters', 'mark.dickinson', 'benjamin.peterson', 'rossburton', 'yan12125']
    pr_nums = ['9085']
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = None
    url = 'https://bugs.python.org/issue34585'
    versions = ['Python 3.8']

    @rossburton
    Copy link
    Mannequin Author

    rossburton mannequin commented Sep 5, 2018

    Currently configure.ac uses AC_RUN_IFELSE to determine the byte order of floats and doubles. This hurts when cross-compiling because a default is set, resulting in Python silently falling back to sub-optimal codepaths.

    A partial improvement would be to not set a fallback, to force the user to set the right byte order explicitly.

    However this test can be done without running anything. autoconf-archive has a macro that uses a carefully constructed double that encodes to an ASCII string in the binary, which is then examined using grep. Evil genius.

    Attached is a POC using this. Currently the autoconf-archive macro only handles big and little endian not the ARM OABI mixed-endian format, so configure.ac assumes if the byte order is unknown then it's the crazy mixed-endian.

    To be honest OABI is so old now, I don't believe anyone actually uses it anymore: everyone still on ARMv4 should have moved to EABI many years ago, and the mixed-endian support could be removed from Py3 in the future.

    @rossburton rossburton mannequin added 3.8 only security fixes build The build process and cross-build labels Sep 5, 2018
    @benjaminp
    Copy link
    Contributor

    New changeset 2a9c380 by Benjamin Peterson (Ross Burton) in branch 'master':
    closes bpo-34585: Don't do runtime test to get float byte order. (GH-9085)
    2a9c380

    @benjaminp
    Copy link
    Contributor

    New changeset b3b8cb4 by Benjamin Peterson in branch 'master':
    run autoconf (GH-9411)
    b3b8cb4

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

    Unfortunately ax_c_float_words_bigendian.m4 evil magical trickery does not work if certain compiler flags are used. Using gcc and -flto seems to be enough to break it.

    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    3.8 only security fixes build The build process and cross-build
    Projects
    None yet
    Development

    No branches or pull requests

    2 participants