search

sandialabs / qthreads

Lightweight locality-aware user-level threading runtime.
https://www.sandia.gov/qthreads/
Other
173 stars 35 forks source link

Regression in detecting host architecture for Apple M1 with 1.20 #262

Closed jabraham17 closed 3 months ago

jabraham17 commented 3 months ago

When updating Chapel to use version 1.20 from 1.19, I noticed a regression in detecting the host architecture on Apple M1.

With 1.19 host was inferred to be aarch64-apple-darwin22.6.0, with 1.20 host was inferred to be arm-apple-darwin22.6.0. This causes the build to fail since there is no fast context support for 32 bit arm.

I think the problem stems from the version of autoconf used when building the release tarball. For 1.19, the autoconf version reported in the config.log (and embedded in aclocal.m4) was 2.71. For 1.20, it was 2.69. This results in a significant diff between the config.guess contained in the release tarball.

The config.guess from 2.71 has the following case, which is missing from 2.69

    arm64:Darwin:*:*)
    GUESS=aarch64-apple-darwin$UNAME_RELEASE

Because this is missing, Apple M1 is inferred to be arm.

A workaround is to just explicitly pass --host when running ./configure, but this seems like a potentially concerning regression

insertinterestingnamehere commented 3 months ago

Interesting find! Thanks for writing up such a thorough report! I'll try regenerating with a newer autoconf and see if that fixes it.

insertinterestingnamehere commented 3 months ago

Okay, I've uploaded a new release tarball that should have this fixed. After generating it with the newer autoconf the config.guess file looks right. When you get the chance, please let me know if that one works okay for you. Thanks!

jabraham17 commented 3 months ago

Thanks for the quick response and fix! After freshly pulling the tarball, I can confirm that the autoconf version is correct, the host architecture is inferred correctly, and everything builds properly.

bradcray commented 3 months ago

Thanks for the quick turnaround, Ian! Just to make sure I'm understanding properly, did this fix not require any changes to the Qthreads sources or version number, just the tarball artifact (such that we can just incorporate it into our build tree and don't need to wait for a new release or anything like that)? Or have I got that wrong?

insertinterestingnamehere commented 3 months ago

Yes, it was just an issue with the tarball and didn't require any source changes whatsoever. I just had to rerun the configure script with a newer version of autoconf.