[MLton] power pc "port"

[Filip Pizlo]

I've overcome all of the linker problems, so that I can build static
libraries for gdtoa and mlton and the linker doesn't complain.  (The fixes
necessary to make this happen are described below.)  However, when I run
the resulting binary, I get:

unhandled exception: Fail: usage: exportMLton worldFile

A few details on how this binary was built:

1) Luke compiled mlton to C using mlton.  The mlton/mlton.cm file was
used.

2) I compiled all of the C files using GCC on my PowerBook, and linked
them with the runtime libs that I had compiled separately.

Any ideas about what could be going wrong?

--

What it took to get mlton linking:

1) I had to insert -D hacks to rename gdtoa's strof and strod, since
libSystem also has these.  This got rid of the linker warnings.

2) I added a PPC implementation of IEEEReal_set/getRoundingMode.  It was
not as easy as the SPARC implementation, because I could not find a
library rutine for doing it - so I had to use the assembly shortcuts in
<ppc_intrinsics.h>.  The code is iffy enough that it would be great to
know which regression tests cover the setRoundingMode function.

3) I set HAVE_TIME_PROFILING to FALSE

4) I had to add initializers to the globals in CommandLine.c environ.c.  
For some reason, the linker was not finding those symbols if they were in
a static library and didn't have initializers.  I've never seen the Darwin
linker behave like this - other code of mine has uninitialized globals
that end up in static libraries.  I'll try to investigate this later.

--
Filip Pizlo
http://bocks.psych.purdue.edu/
pizlo@purdue.edu


On Wed, 1 Sep 2004, Matthew Fluet wrote:

> 
> > Right now, I'm building libmlton as a dynamic lib because static linking
> > is giving me other problems.  So this would explain it.
> 
> Yes.  Looking at things, I think the whole "spawn.h" is a hack.  Under the
> new platform.h setup, I think that cygwin.h and mingw.h should
>  #define HAS_SPAWN TRUE
> and the other unix-y platforms should
>  #define HAS_SPAWN FALSE
> and the spawne.c and spawnp.c files should
>  #if HAS_SPAWN
>  ...
>  #endif /* HAS_SPAWN */
> their contents.  We'd be much better getting linker errors claiming to not
> find MLton_Process_spawn{e,p} than linker errors not finding spawnv{e,p}.
> 
> In any case, you ought to be able to make some progress by some variation
> of the above -- essentially eliminating the spawn{e,p}.c code from the Mac
> OS X platform.
> 
> > Other than the situation with spawnve/p functions, is there any particular
> > reason why libmlton and libgdtoa are static rather than dynamic?
> 
> Probably, but I don't know.
>