bug: Python packaging incompatibility in flet applications on older CPU hardware

[mantarix-dev]

Duplicate Check

• I have searched the opened issues and there are no duplicates

Describe the bug

When using Flet to package desktop (Linux) applications and run embedded Python in the Native layer, an incompatibility issue may be observed with older x86_64 CPUs. This issue usually occurs when the compiled code or binary libraries rely on AVX2 or AVX-512 instructions, while the system in use only supports primitive AVX or older instructions. In such a situation, when running the application or calling embedded Python modules, the following error is usually observed:
Illegal instruction (core dumped)
I tested and ran my built application on new hardware and it ran without any problems, but on an older CPU Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz I am encountering problems. Is there a way to fix this incompatibility in serious python or in the native layer of the flutter project created by flet? Because building the program with Flutter itself and without flet and serious python works perfectly on my old system and the build is done correctly, but when I ran my built program using flet with gdb, it seems like the problem is with the lib project next to the libpython project inside it and its embedded python, but I'm not sure, it seems like somewhere it is using avx2 or avx 512 commands, which causes the program to crash.
Please let me know if there is a solution.
I am using flet version 0.28.3.
I even built the default Flat app but the problem still persists.

Code sample

Code

[Paste your code here]

To reproduce

Many Native packages and layers in Flet (especially when using Flutter for desktop and Python embedded) are compiled by default with modern CPU instruction levels (AVX2/AVX-512) for optimal performance.

Older CPUs that only support early AVX cannot execute these instructions, causing the application to crash.
When running an application built with flet build linux on an older system, a core dump occurs.

I even built the default Flet application, but the problem persists.

Expected behavior

No response

Screenshots / Videos

Captures

[Upload media here]

Operating System

Linux

Operating system details

Debian 13

Flet version

0.28.3

Regression

No, it isn't

Suggestions

No response

Logs

Logs

[Paste your logs here]

Additional details

No response

[FeodorFitsner]

I see. That's because serious_python uses "v3" version of Python binaries:

which requires AVX instructions set:

We could switch to "v2" which uses just SSE or with no optimizations at all.

What do you think?

[mantarix-dev]

@FeodorFitsner So, we can add a tag to separate this action in the build command or the CLI of Serious Python itself, because on most new hardware, for example, on platforms like Android, iOS, and macOS, since most of them are implemented on ARM, this is not a problem.

But the main question is, does this action affect the main functionality of the program?

Doesn't this affect the compatibility and build of Python packages with the x86_64_v2 version?

If not, great, and to get started, do I need to change the Serious Python source to my v2 build or is there a built-in CLI argument for it?

As a suggestion, if there was a section in the CLI of the project build to fully manage the project's build architecture during the project build, it would make it much easier for all these parameters to be automatically managed by Serious Python based on the user's needs

[FeodorFitsner]

Linux Python distros have been re-publihed with x86_64_v2. Delete $HOME/.pub-cache directory, before rebuilding the app. Let me know how it worked.

[mantarix-dev]

@FeodorFitsner It worked great!
I just wanted to know if this works in older versions of flet?
And whether it should be updated to x86_64_v2 for Windows as well and whether there is both Windows ARM and x86 in one file python-windows-for-dart-3.12.zip at https://github.com/flet-dev/python-build/releases?

[FeodorFitsner]

Yes, it will work for both 0.28 and v1 as the same serious_python is used.
For Windows Python packaging takes a different approach - it takes a Windows installer from https://www.python.org/ftp, installs it and then re-pack.