I think it’s possible to use Corellium iPhone emulation for development. Many projects and researchers rely on it. For example, Go language uses it for CI.
Another alternative is to run iOS in QEMU as it had been told already:
10 days? The OCaml ARM64 code generator is in very good shape already, and the recent pull request https://github.com/ocaml/ocaml/pull/9699 adds iOS ARM64 support, which should not be very far from macOS ARM64 support.
However, I would really like to have SSH access to one of those MacMini ARM64 development platforms. That would speed up porting and testing tremendously. Emulators and jailbreaked phones are a pain.
@bluddy not hard, Android needs some patches after Android 5.0, I have it setup for ARM64 and x86_64 at my personal project, also got iOS x86_64 and ARM64.
I have a tooling to cross compile almost anything with esy, similar to ocaml-cross but more versatile and works with essentially any dune package not using cstubs(you need a patch for that). It was working with OCaml 4.08
The patches itself, not great yet, but will open a PR in the future. Also I want to get x86 PIC to work(Android requires that), which is a lot harder than iOS and Android ARM.
The emulator after you get to work is actually nice, works exactly like any VM, SSH and all, if you guys are okay with that I can setup the CI using it.
But also, maybe trying to give Corellium a try? I’m not a huge fan o Go but if they’re using as a CI it’s probably reliable.
Technically even the ABI of the mac ARM is the same as iOS so I would bet 99% is similar, probably same linker, same kernel. But would be great to have the real thing running as there is a lot of small limitations(like stack_size)
That’s amazing, I had started to look on that, but not a lot of spare time, will try to see if it can runs the macOS ARM, as the kernel is really similar
OCaml 4.12 will have full native code macOS/ARM support. The first alpha is due out any day now, and the ecosystem tools will be ready on the day of its release as well, thanks to the OCaml readiness team’s efforts
@EduardoRFS that’s very useful indeed! If you’re able to open a PR against ocaml/ocaml's branch 4.10 with just the code generator backport (and not the iOS-related changes), that would be useful for Homebrew’s macOS OCaml for a month or so until we get 4.12.0 out of the door.
I don’t have a lot of spare time right know, but I opened the PR, left the iOS changes as they’re quite small and I don’t have a macOS ARM box to test right know.
But backporting to 4.11 is easier, as there is no conflict, if you want to try is the same 3 commits on this PR
Try to execute it: opam init. You will be blocked by the macOS security checks, as the binary is not signed.
Open Preferences / Security and Privacy. There should be a notice “opam was blocked because…” and an “Allow Anyway” button. Click on that button.
Try again to execute opam init. You will be blocked again, but now there is an “Open” button. Click on that button. opam init should run and install the OCaml 4.10.2 compiler.
From now on, you can run opam without being blocked. Use this freedom to opam install the packages you need.
Some packages that depend on external C libraries may fail to install because these C libraries are not available. Normally we would rely on Homebrew or MacPorts to provide these C libraries, but these package collections are still being ported to macOS/ARM64.
As a reward for these minor inconveniences, you’ll get excellent performance running OCaml software such as Coq. Single-core performance on a MacBook Air M1 is 20% better than the best x86 workstation I have access to.