Skip to content

Incorrect case string in configure script #120154

Closed

Description

@allsey87

Bug report

Bug description:

I think this:

cpython/configure

Line 12895 in fd104df

Emscripten|WASI)

Should be: Emscripten*|WASI*

I could be wrong, but I think this will never be matched otherwise since even if ac_sys_release is empty, we would be trying to match Emscripten against Emscripten/

CPython versions tested on:

CPython main branch

Operating systems tested on:

Other

Linked PRs

Activity

  1. added
    buildThe build process and cross-build
    on Jun 6, 2024
  2. allsey87 commented on Jun 6, 2024

    @allsey87
    ContributorAuthor

    I think the only reason why this hasn't been an issue/picked up before is that usually, for Emscripten builds, emconfigure is executed instead of configure which sets LDSHARED as an environment variable, causing the entire block to be bypassed.

  3. allsey87 commented on Jun 6, 2024

    @allsey87
    ContributorAuthor

    I can confirm that patching configure enabled me to move forwards. The values in the resulting Makefile now looks closer to what is generated in the Pyodide project with an extra -shared argument passed to emcc.

  4. erlend-aasland commented on Jun 6, 2024

    @erlend-aasland
    Contributor

    Thanks for the report! It sounds like you have a patch ready; would you like to open a PR?

  5. added a commit that references this issue on Jun 7, 2024
  6. added a commit that references this issue on Jun 7, 2024
  7. added a commit that references this issue on Jun 7, 2024
  8. erlend-aasland commented on Jun 7, 2024

    @erlend-aasland
    Contributor

    Thanks for the report and the fix, @allsey87!

  9. vstinner commented on Jun 7, 2024

    @vstinner
    Member

    @allsey87: Thanks for signing again the CLA with your second email address.

  10. added 2 commits that reference this issue on Jun 7, 2024
  11. encukou commented on Jun 10, 2024

    @encukou
    Member

    This broke the stable buildbot wasm32-wasi Non-Debug 3.12, see e.g. here.

  12. allsey87 commented on Jun 10, 2024

    @allsey87
    ContributorAuthor

    Are you sure it was this commit? The error that you are getting sounds unrelated to this change:

    wasm-ld: error: Modules/_testimportmultiple.o: relocation R_WASM_MEMORY_ADDR_SLEB cannot be used against symbol `_testimportmultiple`; recompile with -fPIC
    
  13. vstinner commented on Jun 10, 2024

    @vstinner
    Member

    This broke the stable buildbot wasm32-wasi Non-Debug 3.12, see e.g. here.

    wasm-ld: error: Modules/_testimportmultiple.o: relocation R_WASM_MEMORY_ADDR_SLEB cannot be used against symbol `_testimportmultiple`; recompile with -fPIC
    wasm-ld: error: Modules/_testimportmultiple.o: relocation R_WASM_MEMORY_ADDR_SLEB cannot be used against symbol `_foomodule`; recompile with -fPIC
    wasm-ld: error: Modules/_testimportmultiple.o: relocation R_WASM_MEMORY_ADDR_SLEB cannot be used against symbol `_barmodule`; recompile with -fPIC
    

    The difference between main and 3.12 is that 3.12 tries to build test modules such as _testimportmultiple.

    => I wrote #120309 to fix the issue: on WASI, no longer build test modules on Python 3.12.

  14. added a commit that references this issue on Jun 10, 2024
  15. allsey87 commented on Jun 10, 2024

    @allsey87
    ContributorAuthor

    @vstinner not sure if this relevant, but #120204 did change the flags for the buildbot.

    Previously:

    checking LDSHARED... 
    checking BLDSHARED flags... 
    checking CCSHARED... 
    checking LINKFORSHARED... 
    checking CFLAGSFORSHARED... 
    

    Now:

    checking LDSHARED... $(CC) -shared
    checking BLDSHARED flags... $(CC) -shared
    checking CCSHARED... 
    checking LINKFORSHARED... 
    checking CFLAGSFORSHARED... 
    

    I think this is correct though, and any build configuration relying on those flags not being set would be the problem.

  16. added a commit that references this issue on Jul 11, 2024
  17. added a commit that references this issue on Jul 17, 2024
  18. hugovk commented on Aug 8, 2024

    @hugovk
    Member

    Triage: the linked PRs are merged, can this be closed or is there more to do?

  19. allsey87 commented on Aug 8, 2024

    @allsey87
    ContributorAuthor

    The linked PRs are indeed merged. Closing.

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