Skip to content

Configure EXEEXT hacks are interfering with AX_C_FLOAT_WORDS_BIGENDIAN #125698

Description

@erlend-aasland

Bug report

Bug description:

We mess up EXEEXT in configure.ac:

cpython/configure.ac

Lines 1323 to 1340 in cda0ec8

AC_MSG_CHECKING([for --with-suffix])
AC_ARG_WITH([suffix],
[AS_HELP_STRING([--with-suffix=SUFFIX], [set executable suffix to SUFFIX (default is empty, yes is mapped to '.exe')])],
[
AS_CASE([$with_suffix],
[no], [EXEEXT=],
[yes], [EXEEXT=.exe],
[EXEEXT=$with_suffix]
)
], [
AS_CASE([$ac_sys_system/$ac_sys_emscripten_target],
[Emscripten/browser*], [EXEEXT=.js],
[Emscripten/node*], [EXEEXT=.js],
[WASI/*], [EXEEXT=.wasm],
[EXEEXT=]
)
])
AC_MSG_RESULT([$EXEEXT])

This creates problems1, since AX_C_FLOAT_WORDS_BIGENDIAN expects EXEEXT and ac_exeext to be the same. EXEEXT and ac_exeext are set up by AC_PROG_CC:

AC_PROG_CC

We can mitigate this by:

  1. setting ac_exeext=$EXEEXT after L1340 in configure.ac
  2. use another variable than EXEEXT; for example EXE_SUFFIX
  3. other workarounds?

My gut feel regarding these is that I'd really not like to add more EXEEXT hacks, so I'd like to avoid 1). 2) should be ok, given that no-one else are depending on EXEEXT (cc. @hroncok).

CPython versions tested on:

CPython main branch

Operating systems tested on:

Linux, macOS, Other

Linked PRs

Footnotes

  1. https://github.com/python/cpython/pull/125571#issuecomment-2422385731, https://github.com/python/cpython/pull/125571#issuecomment-2422414137 ↩

Activity

  1. added
    type-bugAn unexpected behavior, bug, or error
    buildThe build process and cross-build
    on Oct 18, 2024
  2. erlend-aasland commented on Oct 18, 2024

    @erlend-aasland
    ContributorAuthor

    cc. @damelang, author of AX_C_FLOAT_WORDS_BIGENDIAN.

  3. erlend-aasland commented on Oct 18, 2024

    @erlend-aasland
    ContributorAuthor

    Another workaround, could be to move the float checks to before our EXEEXT hacks, but who knows what will break next time.

  4. added a commit that references this issue on Oct 18, 2024
  5. hroncok commented on Oct 18, 2024

    @hroncok
    Contributor

    cc. @hroncok

    I am not entirely sure what's my input here supposed to be.

  6. added a commit that references this issue on Oct 20, 2024
  7. added a commit that references this issue on Oct 20, 2024
  8. added a commit that references this issue on Oct 20, 2024
  9. erlend-aasland commented on Oct 20, 2024

    @erlend-aasland
    ContributorAuthor

    I am not entirely sure what's my input here supposed to be.

    I just suspected a third-party consumer of our build system would like to receive a heads-up when I proposed a rename of one of the configure/Make variables.

    Anyway, as I feared, the renaming broke CI, so I'm reverting it. I suggest instead to amend Dan Amelang's patch to use ac_exeext iso. EXEEXT.

  10. added a commit that references this issue on Oct 20, 2024
  11. erlend-aasland commented on Oct 20, 2024

    @erlend-aasland
    ContributorAuthor

    I amended Dan's patch to use ac_exeext in Codespaces, and can confirm that that approach works for WASI.

  12. erlend-aasland commented on Oct 20, 2024

    @erlend-aasland
    ContributorAuthor

    See python/cpython-devcontainers#30 for a proposed patch.

  13. erlend-aasland commented on Oct 21, 2024

    @erlend-aasland
    ContributorAuthor

    I amended Dan's patch to use ac_exeext in Codespaces, and can confirm that that approach works for WASI.

    OTOH, most of the macros in autoconf-archive does actually use EXEEXT, and not ac_exeext, implying that if we should land python/cpython-devcontainers#30, we'd possibly run into a similar issue with another macro at a later point1. Perhaps we should just work around this in configure.ac by making sure ac_exeext is set to the same as EXEEXT.

    Footnotes

    1. yet another reason to switch to a more modern build system ↩

  14. added 3 commits that reference this issue on Oct 25, 2024
  15. added 2 commits that reference this issue on Oct 26, 2024
  16. erlend-aasland commented on Oct 26, 2024

    @erlend-aasland
    ContributorAuthor

    Landed on the following solution:

    Automerge enabled for the backports. Closing this as completed.

  17. added 2 commits that reference this issue on Oct 26, 2024
  18. added 3 commits that reference this issue on Jan 12, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    buildThe build process and cross-buildtype-bugAn unexpected behavior, bug, or error

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions