Support Universal Binaries

[yairchu]

Does/would cosmopolitan support building native x86_64+ARM "Universal Binaries"? So that the same executable would run for example both on x86_64 Windows and on native ARM Linux (without requiring qemu)?

[jart]

APE binaries will run on ARM M1 Macs with Rosetta. APE binaries also run on Windows ARM. The exception is Linux ARM. That's something we intend to do at some point. I'm going to close this out since it's a question not an issue, but thank you for asking it! Please continue to follow the project for updates on ARM.

[yairchu]

Thanks for the quick response!

I'm going to close this out since it's a question not an issue

But now that the question is answered it becomes an issue: Support Universal Binaries

[paulwratt]

I'm watching the box64 repo and thinking of how to update the magic recognition to recognise (and then run) APE binaries - I'm a bit busy at the moment tho

BTW they already have Box64 running x86_64 on RISCV

[paulwratt]

One issue I can see, although more of a side effect, is that the resulting binaries would have x86_64, aarch64 and riscv64 code blocks inside them, and that definitely would qualify them as "Fat Binaries", but I can see how useful that would be with modern equipment.

EDIT: I shall coin the phrase here "Fat64 Binaries - are a thing" (in the future) - in the meantime, I think the box64 route will be more lucrative, as the resulting binary is still kept small - Note that we do do a similar thing on m68k AtariST MiNT, where we have multiple (sometimes incompatible) codepaths in the same binary (which allows to "fail gracefully"), and that the original .dmg were also "dual architecture"

[jart]

Are you suggesting we embed box64 binaries inside APE binaries? Box64 builds a 16mB binary. It doesn't support big endian. Blinkenlights on the other hand is 200kb and endian agnostic. We could embed a build of that for aarch64, s390x, m68k, and risc-v and binaries would still be less fat than Go hello world.