[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