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

[Vesa Karvonen]

On Mon, Nov 17, 2008 at 1:42 PM, Wesley W. Terpstra <wesley at terpstra.ca> wrote:
> Never heard back from you about this ...
>
> ---------- Forwarded message ----------
> From: Wesley W. Terpstra <wesley at terpstra.ca>
> Date: Wed, Nov 12, 2008 at 12:56 AM
> Subject: Re: [MLton] Re: [MLton-user] SVN r6941 MLton/MinGW32 and FFI
> To: Matthew Fluet <fluet at tti-c.org>
> Cc: "mlton at mlton.org" <mlton at mlton.org>
>
>
> On Wed, Nov 12, 2008 at 12:26 AM, Matthew Fluet <fluet at tti-c.org> wrote:
>>> So why were the dl* functions added to mingw.c in the first place?
>> 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.

> 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.

-Vesa Karvonen

#1) I might add here that a singly linked list would work just as well.