Possible build regression in 3.13.1 with `-latomic` on MIPS

[zanieb]

Bug report

Bug description:

Hey! I'm still learning about these things, but I noticed a difference between 3.13.0 and 3.13.1 and want to confirm if this intentional.

In python-build-standalone, we validate the linked libraries after building a distribution. Both the free-threaded and default variants of Python 3.13.1 failed this validation due to a link to atomic on the following target triples:

• mips-unknown-linux-gnu
• mipsel-unknown-linux-gnu

I'm not sure why the inclusion is limited to these targets yet.

I added an exception to our validation for now, but we're concerned about the additional system requirement and would prefer to remove it. I'm not sure what changed, but it looks like there's a relevant news entry linking to #125269.

Note that we apply patches to CPython before building, it's possible this is just our bug.

Related:

• cross-compile error: undefined reference to `__atomic_load_8' #125269
• gh-125269: Use AC_LINK_IF_ELSE to detect if -latomic is needed #125416
• libatomic dependency may be problematic astral-sh/python-build-standalone#410
• Update to latest Python patch versions astral-sh/python-build-standalone#400

CPython versions tested on:

3.13

Operating systems tested on:

Linux

[zanieb]

cc @colesbury — no pressure of course but it seems likely you have the relevant context here.

[colesbury]

Are you cross compiling for mips? The change from 3.13.0 to 3.13.1 was #125416 (which you linked to). Previously, we were using AC_RUN_IF_ELSE to detect if -latomic is needed, which always omitted it when cross compiling. Now (in 3.13.1), we are using AC_LINK_IF_ELSE, which checks if linking works and correctly (???) determines if -latomic is needed when cross compiling.

I have questions:

• Did the 3.13.0 binary actually work on MIPS if it wasn't linked with libatomic?
• Did anyone actually run the 3.13.0 Python binary on MIPS?
• Does anyone actually run anything on MIPS?
• Didn't MIPS Technologies go bankrupt?
• Didn't MIPS Technologies then abandon MIPS in favor of RISC-V?
• Why isn't it called RISC-V Technologies now?

[zanieb]

Thanks for the quick reply.

Yeah it's a cross-compile, so... perhaps it was wrong before? We do a lot of cross-compiles though and, to my knowledge, the other targets are working.

Those are some good questions — I don't have good answers.

As far as I can tell, the python-build-standalone project:

• Does not publish MIPS distributions
• Does not run tests on the MIPS distributions

Support was added back in 2021 astral-sh/python-build-standalone#60 (comment) — there haven't been particularly clear updates around the status of the targets since then.

From my understanding of the linked issues and your summary, it sounds like there's probably not a bug here. I think the only outstanding item is for me to confirm that the other cross-compiles are functioning as intended, which may require some understanding of this MIPS issue but 🤷‍♀️ frankly, it doesn't seem worth the time of python-build-standalone or CPython maintainers to look into what's happening with MIPS unless it informs some broader problem with cross-compiles.

cc @indygreg perhaps you have a better perspective on the value of these distributions? edit: opened astral-sh/python-build-standalone#412 for discussion of this on the proper repository.

[erlend-aasland]

Is this still relevant after #125416 landed?

[zanieb]

Yeah #125416 predates this issue — it's the reason for the change in behavior reported here.