Re: Cross-compiling a binary to a new OS

On Sat, May 30, 2015 at 10:39 AM, Konstantin Tcholokachvili
<[email protected]> wrote:
> I'm making an operating system for PowerPC Macs and I want to try to launch
> a statically linked "Hello world!' application compiled with MLton.
> I saw in 'bin/add-cross' script that ssh is needed on the target computer
> but the OS I'm playing with haven't even a TCP/IP stack.
> So, isn't it possible to modify that script without needing ssh or am I not
> foreseeing something which halts such hacks?
>
> I already have cross-compiled gcc and other GNU tools for powerpc (32 bits).
>
> Thank you in advance for a piece of advice,

There are some more details on porting and cross compiling at:
  http://mlton.org/PortingMLton
  http://mlton.org/CrossCompiling

The use of ssh isn't essential; it's just an easy way of compiling and
running C code on the target where there is not yet a MLton.  While
you can do most of the compiling on a host machine with suitable gcc
cross-compiling support, there are a few instances where executing on
the target machine is required.

If you look at /usr/lib/mlton/targets/self (or
<src>/build/lib/targets/self), you will see the target dependent files
that must be present for cross-compiling support with MLton.  It
should be possible to generate the various lib*.a archives on the host
machine with suitable gcc/binutils cross-compiling support.  The arch
and os files are just simple text files with the target architecture
and operating system descriptions.  The other files are:
  constants
  sizes
  include/c-types.h
  sml/c-types.sml
These are also all simple text files, but the various constants that
they represent depend upon the target characteristics.  It is for
generating these values that it is helpful to execute on the target
machine.  The sizes, include/c-types.h, and sml/c-types.sml files are
all targets of the <src>/runtime/Makefile (around lines 199 and 363).
It looks as though gen/sizes has a dependency on libmlton.a, but I
think that could be relaxed -- it's really just performing sizeof
calculations.  The constants file is a target of the <src>/Makefile
(around line 107).  This determines a bunch of compile-time C
constants that are generally hidden behind C macros, which makes them
difficult to import in to SML code as C identifiers.  There is a
slight level of indirection that requires compiling and linking a
small C program with the libmlton.a runtime and then executing it to
determine the values of the constants.  The level of indirection comes
from files like <src>/runtime/basis/Posix/Signal-consts.c, which
defines C symbols (with names that mimic where we want the values to
appear in the SML Basis Library implementation) that are defined to be
equal to various SIG* values.  In theory, all of the values determined
in the constants file are, in fact, compile time C constants -- if
they are not, then it really wouldn't be appropriate to treat them as
such in the Basis Library implementation.  It wouldn't be incorrect to
treat all of these values as runtime imported values; it might be an
interesting experiment to measure the performance impact of simply
importing them as C symbols.  In any case, I don't really know of a
good way of driving a C compiler so that it will simplify and display
compile-time constants in a manner that can be shunted into a
supporting file.

With the exception of the constants file, you could probably build the
other target dependent files by hand if you know the characteristics
of the target machine.  Or, just move the appropriate files back and
forth to the other machine via some other mechanism.  The
bin/add-cross script shows the steps that you need to go through; you
could simply replace all of the ssh-ing by some other mechanism.

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

------------------------------------------------------------------------------