[MLton-user] Unable to build a Win64 hosted version of MLton

Nicolas Bertolotti Nicolas.Bertolotti at mathworks.fr
Wed May 11 03:21:25 PDT 2011


FYI,

The issue I have been facing comes from the version of GMP I compile MLton with which is not the same than the one that comes with the MLton installer package.

The gmp.h file contains the following stuff:
#if ! defined (__GMP_WITHIN_CONFIGURE)
#  if defined( _MSC_VER )
#    if defined( _WIN64 )
#        define __GMP_BITS_PER_MP_LIMB    64
#        define GMP_LIMB_BITS             64
#        define SIZEOF_MP_LIMB_T           8
#        define _LONG_LONG_LIMB                                             1
#    elif defined( _WIN32 )
#        define __GMP_BITS_PER_MP_LIMB    32
#        define GMP_LIMB_BITS             32
#        define SIZEOF_MP_LIMB_T           4
#        ifdef _LONG_LONG_LIMB
#          undef _LONG_LONG_LIMB
#        endif
#    else
#        error This is the wrong version of gmp.h
#    endif
#  endif
#  define GMP_NAIL_BITS                      0
#endif
... and, as the MinGW compiler does not define "_MSC_VER", _LONG_LONG_LIMB is not defined. Problem solved...

Anyway, it may not be important but I could see the following assertion in runtime/gc/int-inf.c :
  assert ((res->_mp_size == 0)
          or (res->_mp_d[(res->_mp_size < 0
                          ? - res->_mp_size
                          : res->_mp_size) - 1] != 0));
I don't know if this could happen for some targets but, if mp_limb_t is 32 bits and objptr is 64 bits and we manipulate a small IntInf value (say 1), it seems to me that _mp_size will be set to 2 but _mp_d[1] will equal 0 and the assertion will fail. Though the "production" version does not enable assertions, I guess it is there for some reason and maybe the algorithm will fail elsewhere.

One additional thing about the underscoring on mingw w64. I can guarantee that the MS compilers do not introduce a leading underscore but mingw w64 does (try building a simple C file with an external symbol with MS and MinGW w64 and run "objdump" on it). Based on the information I grabbed on the Web (well, on some forums so it may not be that reliable), it seems that the guys from mingw w64 have done it on purpose because, at the beginning, the port was not mature enough to link against MS compiled DLLs and this was a way to restrict the usage to the "gcc" world. Now, we can find some versions (the one I downloaded from "drangon") which no longer introduce this leading underscore ... Anyway, I don't know if this is the new official behavior or not.

Cheers

Nicolas

From: Wesley W. Terpstra [mailto:wesley at terpstra.ca]
Sent: Monday, May 09, 2011 5:46 PM
To: Nicolas Bertolotti
Cc: mlton-user at mlton.org
Subject: Re: [MLton-user] Unable to build a Win64 hosted version of MLton

On Mon, May 9, 2011 at 5:16 PM, Nicolas Bertolotti <Nicolas.Bertolotti at mathworks.fr<mailto:Nicolas.Bertolotti at mathworks.fr>> wrote:
Their 64 bit version appears to be more conformant to what the MS tools do with the symbols (e.g. no extra "_") which requires to change mlton/main/main.fun to set Control.labelsHaveExtra_ to false for the amd64-mingw target.

FWIW, the leading _ comes from msvcrt... ie: Microsoft.

May you please tell me where you got the "mingw" version that you included in the MLton installer?

http://sourceforge.net/projects/mingw-w64/

... but I took a snapshot some time ago after I found a version that passed all the regressions for MLton. We currently just use this (now quite well tested) snapshot on <http://mlton.org/pages/Experimental/attachments/>.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mlton.org/pipermail/mlton-user/attachments/20110511/1099c806/attachment.htm


More information about the MLton-user mailing list