[MLton] MLton on Debian hppa, powerpc, and sparc

[Wesley W. Terpstra]

On Aug 24, 2005, at 6:31 PM, Stephen Weeks wrote:
> I've uploaded an experimental package of MLton to Debian unstable.

Quick question: why is mlnlffigen built, but not installed?

Since you uploaded a new source version, it is not possible to upload my
old packages (they are older than source), so I've had to rebuild  
mlton on
each platform.

>   Package declares a build time dependency on mlton (>= 20020410.1)  
> which cannot be satisfied on powerpc. Package mlton does not exist  
> on powerpc.

I've uploaded a package for this.
There was a problem in that
   mlton/lib/mlnlffi/internals/c-int.powerpc-linux.mlb
did not exist. After copying c-int.x86-linux.mlb, it worked.

(c-int.powerpc-darwin.mlb would be nice too)

Despite my earlier efforts, there is STILL only 320M RAM on voltaire.
Maybe now would be a good time to ask what happened to the chip.
Since I use a powerpc myself, I built it on my own machine instead.

>   Package declares a build time dependency on mlton (>= 20020410.1)  
> which cannot be satisfied on sparc. Package mlton does not exist on  
> sparc.

This is still rebuilding; it will probably take a few days.
For reference, I am using vore (500M RAM).
Again, c-int.sparc-linux.mlb needed to be created.

>   Package declares a build time dependency on mlton (>= 20020410.1)  
> which cannot be satisfied on hppa. Package mlton does not exist on  
> hppa.

I am getting a Bus error when using mlton.
The exact same package that used to work, now does not.
I suspect a kernel change, and am looking into it.

Also, debian/sid made a transition to g++-4.0.

This resulted in an ABI change for c++ libraries, including libgmp3.
Since mlton only uses the C api, it worked even with the new library.
Nevertheless, the old .deb depended on libgmp3 and libgmp3-dev
which can not be simultaneously installed (libgmp3-dev depends on
libgmp3c2---the gcc 4.0 version).

I got flamed on #debian-devel b/c they didn't like a package which
builds itself. However, I think they are mistaken, and it is the right
thing to do. Nevertheless, having mlton depend on both the shared
library and the development headers is a recipe for trouble if this
happens again. So, maybe (for mlton only) it makes sense to staticly
link in libgmp. This way, any version of libgmp3 can be installed
for building the new mlton. OTOH, if there is a security problem with
libgmp3, a new upload of mlton will be required.