search

MLton / mlton

The MLton repository
http://mlton.org
Other
960 stars 127 forks source link

How to get started on arm #510

Closed nobrowser closed 12 months ago

nobrowser commented 1 year ago

Hi, looks like I won't be the first to abuse the issues feature for asking a question :-P

How can I bootstrap mlton on debian arm i.e. aarch64? There is no debian package (at least not in the current release), and I don't see a binary download on the mlton website for this platform. Am I just out of luck ? :(

-- Ian

MatthewFluet commented 1 year ago

If you have a working MLton on one platform (e.g., amd64-linux) and SSH access to another platform (e.g., aarch64-linux), then you can use make remote-bootstrap to build a binary package for the target machine. See http://mlton.org/PortingMLton#_bootstrap for more details. For the best results, I would suggest checking out the current git sources, building MLton on amd64-linux (i.e., make), and then doing the remote bootstrap (make remote-bootstrap).

nobrowser commented 1 year ago

Yes, this appears to work. Many thanks for the advice and for providing the bootstrap script, I imagine it was quite of bit of unexciting work. I am curious, though: it really only works if I first build the native compiler in the same source tree and then "promote" it, i.e. set OLD_MLTON_DIR to where the just built native compiler is. It does not work if I start with the installed mlton on the host system, even though it is exactly the same version - in this latter case I get an error like "unknown target arm64-linux". What's the secret to success in the former case?

MatthewFluet commented 1 year ago

You shouldn't need to set OLD_MLTON_DIR for make remote-bootstrap after a make to build the current sources on the current platform. If <root>/build/bin/mlton exists, then it will be added to PATH by make. The place where we use mlton on the host machine is the remote--gen-bootstrap-compiler-files (https://github.com/MLton/mlton/blob/master/Makefile#L641-L643).

The unknown target arm64-linux using the system mlton is due to the fact that the runtime files built on the remote target are only installed in <root>/build/lib/mlton/targets, not in /usr/lib/mlton/targets, by remote--recv-runtime (https://github.com/MLton/mlton/blob/master/Makefile#L636-L639).

So, I guess it isn't "For the best results"; it is required to first build the current sources on the host and then do the remote bootstrap. It would be a little dangerous to add a new target to the system mlton for a few reasons. First, it would typically require elevated permissions. Second, the system mlton and the Git sources mlton would need to agree on details of the runtime system (in particular, the details of the targets/<arch>-<os>/contants file, though that does not change very often), else using the system mlton to build the bootstrap compiler sources might fail or might succeed but be incompatible with the target platform runtime library (which was build from the Git sources).

Probably best to add a check at the beginning of make remote-bootstrap to ensure that a <build>/bin/mlton exists for generating the bootstrap compiler sources. Or add a $(MAKE) at the beginning to ensure that we have a current built version of the compiler.

nobrowser commented 1 year ago

Thanks for the explanation!

If ./build/bin/mlton is a target in the Makefile (and it should be, no?) a cleaner solution than either of the ones you propose is to just add it as a dependency to the remote-bootstrap rule.

MatthewFluet commented 1 year ago

The Makefile isn't quite that clean; ./build/bin/mlton isn't a target; it is a side-effect of the top-level compiler pseudo-target.