[MLton] Possible bug in MLton-7230.msi for MinGW and 64 bit
questions
Wesley W. Terpstra
wesley at terpstra.ca
Sun Nov 1 11:46:37 PST 2009
On Sun, Nov 1, 2009 at 3:43 AM, David Hansel
<hansel at reactive-systems.com> wrote:
> whereas with the 7230 version, the constants from
> MLton\lib\mlton\sml\mlnlffi-lib\memory\platform\rtld-flags.mingw.sml
> are used which are defined as
> val RTLD_GLOBAL = 0wx2
> val RTLD_LAZY = 0wx0
> val RTLD_LOCAL = 0wx4
> val RTLD_NOW = 0wx0
These match the dlfcn we got from
http://code.google.com/p/dlfcn-win32/downloads/list
So the newer version of MLton is correct.
Inspecting the code for dlfcn reveals that only the RTLD_GLOBAL flag
has any effect at all. All other flags are ignored on windows.
With the old (incorrect flags) "global=true,lazy=true" -> 0x101, which
means: do nothing. That's because the actual flag for global is 0x2.
The new MLton gets it correct and uses 0x2 for the flags you provided.
The end result of this is that the new MLton is actually honouring the
global=true option whereas the old version was silently ignoring it.
> After changing the constants in rtld-flags.mingw.sml to the values from the previous
> version, the crashes went away. Our code calls DynLinkage.open_lib with
> parameters "global=true" and "lazy=true", so the values of the constants
> definitely come into play.
Why are you setting "global=true"? Do you load subsequent libraries
that depend on earlier loaded libraries?
> Should we be using different parameters or is this a bug in MLton?
A mixture of both. The *older* MLton had a bug, which is resolved in
the newer MLton builds. To reproduce the behaviour you had before,
switch to "global=false".
More information about the MLton
mailing list