Remove global simd build flags

[gnattu]

This removes the globally applied -msse4.2 and -maes build flags, unbreaks the old CPU compatibility.

The performance critical paths already have runtime-dispatched SIMD/AES implementations when needed and the runtime CPU supports it, the global flags benefits little but makes older CPUs can no longer use this lib.

I do not personally own a CPU which is that old, but I emulated core2-duo with qemu-user and the libs are loadable with this emulated CPU.

Fixes ericsink/SQLitePCL.raw#652,
And ultimately, fixes jellyfin/jellyfin#15148

[Chuckame]

@ericsink would you be able to review this PR?

[ericsink]

would you be able to review this PR?

Working on it...

[kasperk81]

note x86-64-v2 is baseline starting from .NET 11: https://learn.microsoft.com/dotnet/core/whats-new/dotnet-11/runtime#x86x64-requirements

For all three operating systems (Apple, Linux, and Windows), the baseline is updated from x86-64-v1 to x86-64-v2. This changes the hardware from only guaranteeing CMOV, CX8, SSE, and SSE2 to also guaranteeing CX16, POPCNT, SSE3, SSSE3, SSE4.1, and SSE4.2. This guarantee is required by Windows 11 and by all x86/x64 CPUs officially supported on Windows 10. It includes all chips still officially supported by Intel and AMD, with the last older chips having gone out of support around 2013.

not supporting over a decade old hardware isn't so bad considering <1% users would have such an ancient system lying around and highly doubtful they are using it for anything serious

[gnattu]

not supporting over a decade old hardware isn't so bad considering <1% users would have such an ancient system lying around

I can understand the maintenance complexity problem for ancient devices but I do not see "too hard to maintain" issue here, unless I missed something? This is just a couple of build flags, and dotnet 10 LTS will still receive support until November 14, 2028, which means those older CPUs still have two more years to be totally phased out in dotnet ecosystem.

and highly doubtful they are using it for anything serious

If that is true this PR won't be here in the first place. We received a bunch of user reports that Jellyfin crashed after updating and we identified the issue was the CPU being too old. I do agree those older CPUs will suffer running Jellyfin in a lot of cases, but a lot of our users are happy with that, and some of they even spent extra effort to download older version's sqlite integration to keep running our latest version. At least for those users, this support does matter.

[ericsink]

We do plan to fix this. In fact, I tried doing so recently, but it caused some build breakage, and I haven't tracked down the problem yet. Hopefully soon.

[kasperk81]

If that is true this PR won't be here in the first place. We received a bunch of user reports that Jellyfin crashed after updating and we identified the issue was the CPU being too old. I do agree those older CPUs will suffer running Jellyfin in a lot of cases, but a lot of our users are happy with that, and some of they even spent extra effort to download older version's sqlite integration to keep running our latest version. At least for those users, this support does matter.

.NET 11 has dropped the support for hardware not supporting v2 which has SSE4.2 among other things, so what now for those users? of course someone can run qemu with pentinum 4 settings and test modern software for fun but that's not a production scenario anyone is serious about. it's not about one lib, it's the entire spectrum of .net ecosystem dropping that support with .net 11 onwards, all native dependency (coreclr, jit, aot, r2r several tools).