[MLton] Re: [MLton-user] SVN r6941 MLton/MinGW32 and FFI

[Wesley W. Terpstra]

On Mon, Nov 17, 2008 at 3:51 PM, Vesa Karvonen <vesa.a.j.k at gmail.com> wrote:

> >> Looks like the origin was to get mlnlffi working on MinGW:
> >>  http://mlton.org/pipermail/mlton/2006-November/029349.html
>
> Yes, that is why I initially wrote them.  It is a minimal
> implementation and doesn't necessarily work as an absolute complete
> replacement for dl* functions.


Ok, so we can remove the MLton ones? I think they are broken atm anyway
since they get prefix with MLton_ by the mingw.h.

> Using dlfcn-win32 does seem the best approach. I'd like to hear
> > something from Vesa before removing them.
>
> Frankly, after a very brief look at the code of dlfcn-win32
> (http://code.google.com/p/dlfcn-win32/source/browse/trunk/dlfcn.c),
> I'm not very impressed with it.  I may be mistaken and it might be
> mostly harmless, but it seems to leak library handles when RTLD_GLOBAL
> is specified.  Specifically, the code seems to first execute
> LoadLibraryEx, which increments the reference count of the library,
> then if RTLD_GLOBAL is specified, the library handle is added to the
> doubly linked list (#1) --- except when the library was already
> loaded, in which case no matching call to FreeLibrary seems to be
> made, which means that the handle was leaked.
>
> But, it is probably better to use it anyway (at least after all the
> obvious bugs have been fixed), because then we don't have to maintain
> a similar library.


Since you are obviously the resident expert, maybe help them it? I was
thinking we could just include their (fixed) library in the MLton mingw
installer. That way things will just work for users by adding -ldl, but
otherwise we don't throw these symbols into your program. This seems the
ideal solution to me since as DLL the wiki _import libdl examples will work
unchanged with their default external scope.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mlton.org/pipermail/mlton/attachments/20081117/10d0eb12/attachment.html