lazymio

The `manylinux1` hack is known outdated but I also don't think dropping `manylinux` is a good choice for pip.

> I see but what I meant is whl filename should not be touched. Rather it should be used proper platform/docker to build a whl for maximum compatibility and during...

> Main issue here is you are not considering there is also `musllinux` images so you are forcing putting `manylinux1` during building even when wheel will not be created on...

> Any updates? I once tested this approach and got some problems I remember... I will retry asap.

I read through [the docs](https://packaging.python.org/en/latest/specifications/platform-compatibility-tags/#platform-compatibility-tags). Seems that we should have something like `unicorn-2.0.2-py2.py3-none-manylinux2014_x86_64.whl`. What surprises me is that, `musllinux` is not included in `manylinux`?

Regarding PEP656, I think the correct way to do this is to add a brand new wheel (i.e. build wheel on alphine containers instead of manylinux) because much of our...

Hello, nice contribution and looks good. However, before getting merged, changes you need to do at least include: - Add `UC_ARCH_LONGARCH` and related `UC_MODE` definitions to unicorn.h - Add a...

@bet4it I see. Anyway I can test this?

> Why not add LoongArch support in your `DebianOnQEMU` project😄 QEMU supports that? I will check and build ;)

Doesn't build on current Debian rootfs because kernel building has not been merged so far and compilers lack linux headers. Tried on Loong Archlinux, `gcc` core dumped while clang give...