we should not be incestuous

[Henry Cejtin]

But  this  is  really terrible.  MLton source should not depend on MLton.  It
should be straight ML.  Also, when I program, in general I  do  not  want  to
program  in MLton dialect of ML, I want to program in standard ML.  This kind
of `incestuousness' is really not a good thing.

This seems to me to really be a strong argument for what I mentioned  before:
when  you  compile  using  MLton  there is NO MLton structure.  You just have
standard ML.  If you want more, you have to add an entry  to  your  .cm  file
which consists of something like
    $MLton/mlton.cm
or  something  like  that.  Then their should be a flag for the `-stop f' and
`-stop sml' arguments which makes this be the approriate set of stub files.

(This reminds me: the man page for MLton with the latest RPM thinks  that  it
is `-stop m' instead of `-stop sml'.)

What are you using out of the MLton structure?

As  to  making  RPMs that will work for Red Hat 6.* machines, I don't believe
that you can.  The problem of the shared libraries is  no  big  deal  because
that  can  be  worked  around by using i386-glibc21-linux-gcc, which is a gcc
which calls the C compiler with the right libraries to make executables  that
use the older shared libraries.  Unfortunately, the problem of the actual RPM
itself is different.  Around here I keep some machines running  Red  Hat  6.*
just so that I can build old RPMs.