13 Platform-specific notes
This section discusses issues that arise when running or building
MLton on various platforms.
Here are some issues that apply to building MLton on many
platforms.
- MLton Makefiles use GNU extensions, so you must have
GNU make available.
13.1 Running on Cygwin/Windows
MLton uses the Cygwin
emulation layer to provide a Posix-like environment while running on a
Windows machine. To run MLton on Windows, you must first install
Cygwin on your machine. To do this, visit the Cygwin site from your
Windows machine and run their setup.exe script. Then, you can
unpack the MLton binary tgz in your Cygwin environment.
To run MLton cross-compiled executables on Windows, you must
install the Cygwin dll on the Windows machine.
Here are the known problems using MLton on Cygwin.
- Time profiling is disabled.
- Posix.Process.fork is disabled. Any use of fork will
raise OS.SysErr. For idiomatic uses of fork plus exec, you can instead use the MLton.Process.spawn family of
functions, which work on both Cygwin and Linux.
Fork used to be disabled due to Cygwin bugs involving the interaction
of fork and mmap. Recently, Cygwin developers have fixed those bugs,
in Cygwin versions from 2004-Jul-15 or later (1.5.11-1 or higher).
However, Cygwin's mmap emulation does not make available as much
contiguous virtual address space as using the Windows VirtualAlloc function. Hence, MLton still uses VirtualAlloc
and not mmap, which means that Cygwin can not properly emulate fork.
Consequently, Posix.Process.fork must be disabled.
13.2 Running on PowerPC/Darwin
Here are some things that may affect performance on PowerPC.
- When compiling for PowerPC, MLton only supports the C code
generator (-codegen c). Hence, performance is not as good as it
might be and compile times are longer. Also, the quality of code
generated by gcc is important. By default, MLton calls gcc -O1. You can change this by calling MLton with -cc-opt
-O2.
13.3 Running on FreeBSD
Here are the known problems using MLton on FreeBSD.
- The executables often run more slowly than on a comparable Linux
machine. We conjecture that part of this is due to costs due to heap
resizing and kernel zeroing of pages. Any help in solving the problem
would be appreciated.
13.4 Running on Linux
The are no known problems using MLton on Linux.
13.5 Running on MinGW/Windows
Here are the known problems using MLton on MinGW.
- Many of the Posix functions are unimplemented and will
raise SysErr.
- MLton.Itimer is unimplemented.
- The C function getrusage is implemented by a stub that
always sets the time to zero. Hence MLton.Rusage.rusage will
return times of zero. Also, the times printed by the runtime system
will be zeroes.
13.6 Running on NetBSD
The are no known problems using MLton on NetBSD.
13.7 Running on OpenBSD
Here are the known problems using MLton on OpenBSD.
- Our socket regression test fails. We suspect this is not a bug
and is simply due to our test relying on a certain behavior when
connecting to a socket that has not yet accepted, which is handled
differently on OpenBSD than other platforms. Any help in
understanding and resolving this issue is appreciated.
13.8 Running on Sparc/Solaris
Here are some things that may affect performance on Sparc.
- When compiling for Sparc, MLton only supports the C code generator
(-codegen c). Hence, performance is not as good as it might
be and compile times are longer. Also, the quality of code generated
by gcc is important. By default, MLton calls gcc -O1.
You can change this by calling MLton with -cc-opt -O2. We
have seen this speed up some programs by as much as 30%, especially
those involving floating point; however, it can also more than double
compile times.
- When compiling for Sparc, MLton uses -align 8 by default.
While this speeds up reals, it also may increase object sizes. If
your program does not make significant use of reals, you might see a
speedup with -align 4.
Here are the known problems building MLton on Sparc/Solaris.
- You must install the binutils, gcc, and make
packages. You can find out how to get these at
sunfreeware.com.
- Making the documentation requires that you install latex
and dvips, which are available in the tetex package. It
also requires hevea, for which we haven't yet tracked down a
package.
- Bootstrapping is so slow as to be impractical (many hours on a
500MhZ UltraSparc). For this reason, we strongly recommend building
with a Linux to Solaris cross compiler (Section 14).