RE: Naked DllMain in win32_threads.c (boehm-gc)

["Boehm, Hans" <hans_boehm at hp dot com>]

> BTW, win32_threads.c seems to use a "_DLL" guard all over the
> place but I couldn't find anyone who actually defines it - the
> closest seems to be a definition of GC_DLL instead. What gives?
> 
My impression is that Visual C++ tends to define _DLL if it's generating or linking against a dynamic library.

You can find some of the reasoning that preceded this at http://gcc.gnu.org/ml/java-patches/2002-q1/msg00177.html.  But I wouldn't bet large sums of money that this code makes sense.

I think the reasoning here went something vaguely like:

1) The GC can't actually scan static variables from dynamic libraries with mingw32, since that causes the OS to asynchronously unmap stuff out from under the GC.  If the GC were built with MS tools, we compensate with a structured exception handling hack.  But gcc doesn't support that.  See http://gcc.gnu.org/ml/java-patches/2002-q1/msg00652.html .

2) Since DLLs don't work, we have to do things differently with MINGW32.  However we might eventually fix that.  In that case presumably both __MINGW32__ and _DLL would be defined, and we would resort back to the old way of doing things.

Hans