No rule to make target none.o’, needed by libasmrun.a'. Stop.
I looked the message up and it seemed to indicate that ocamlopt failed to build. Sifting through the npm build log I couldn’t tell if that is the case. I could only see that ocamloptp seemed to have succeeded.
Has anyone succeeded in building bs-platform for M1 native? I have nodejs 15 built from the source using nvm. My system OCaml (4.10.2) was bootstrapped with @avsm’s OPAM native M1 binary. So building that version of OCaml is not a problem but it is possible there are issues with the version of OCaml bs-platform uses.
Did you try rosetta?
I heard people have successful stories installing it using Rosetta.
Note I don’t have M1 machines so I would not expect we will have a native M1 binary in the near future. I expect we may have a native support for Arm later this year
I am (irrationally) trying to build everything native so I have not tried Rosetta yet. So far everything works smoothly with my OCaml on M1 native. Could you maybe share an npm build log for bs-platform so I can check how far my build was able to go and where the failure is in the process?
According to this message there are definitely issues with building older versions of OCaml compilers. From my build log it looks like ../boot/ocamlrun ../boot/ocamlc runs fine. So instead of bootstrapping 4.06.1+BS completely from scratch with itself, do you think compiling it with system OCaml might work? (so that ocamlopt does not have to be bootstrapped and presumably your compiler targeting JS does not depend on the native code generation/optimizer part of OCaml).
If you are willing to add an option to build bs-platform using system OCaml I would be happy to give it a try and report back the results.
Hi, the whole ReScript compiler is just a file so that it should just compile on reasonable ocaml compilers.
The other thing we can do is that we can also upgrade the compiler.
The main thing is that I don’t have M1 machines. So if anything goes wrong, the ping back loop would be very long and it is not fun – I would suggest you be a little patient. I heard that bs-platform running on rosetta is still faster than the old ones.
I think it’s still too early to have a 100% native M1 setup at the moment. It’s a fun experiment, and the list of tools that support native is growing constantly, but I expect it’ll be a few months to a year before this sort of goal is viable in a development environment.
I looked into this a bit more. My current OCaml M1 support on 4.10.2 is super solid. The main PR came from @EduardoRFS. However 4.10.2 is quite a few commits ahead of 4.6.1, particularly the runtime code has since been restructured and domain state support was added in the runtime.
If we look at some of the the earlier work on iOS support by @whitequark, the closest to 4.6.1 is possibly the 4.07+ios branch of the esy-cross fork, which is ahead of BS, or the default ios branch, which is behind. It is not clear that 4.07+ios even compiles but apparently the ios default branch did work on jailbreaked iphones or on emulators.
The @EduardoRFS PR covers the earlier work but also changed some register assignments to support shared library calling convention on macOS and also requires the ABI changes provided in #9752.
In summary to get native M1 support one needs to back port #9699 and #9752 or rebase BS off 4.10.2.
(I had to break my response into two parts because I am only allowed two links in each post).
Upgrading the version of OCaml used by ReScript is not a simple process, and it sounds like the backports would also be difficult due to the age of the 4.06.1 compiler.
As @Hongbo said he can’t do much without M1 hardware to test on. You’ll just need to be patient and accept that at least for now bs-platform requires rosetta to operate.
I will soon also have an M1 to test on. I guess the easiest is to defer to the compiler upgrade, because then cross compilation is almost free. If I remember correctly this is actually planned for this year.
Thanks and no worries! I know I could always use Rosetta or Windows. I just feel motivated to look under the hood and learn the nuts and bolts a little. I am a little surprised by the tight coupling to the compiler backend. As I understand it BS takes over prior to byte code generation so it should not really depend on asmcomp, other than using the optimizer to produce a native version of itself. Ideally BS should be able to be compiled by any version of OCaml despite the fact that it borrows a part of the OCaml compiler. So if 4.06 is good enough for the purpose BS should never have to upgrade just to be able to get compiled to binaries. For example a later version of gcc should certainly be able to compile an earlier version of itself (to a reasonable extent), no? I would like to understand why this breaks down here. Is it because lots of stdlib or whatever other parts of the compiler are implemented in C and OCaml compilers implicitly make assumptions about these?
@jfrolich Could you expand on why cross-compiling helps here? It still requires a bump in compiler version right? OCaml already runs on M1 natively with 4.10.2.
in each post).