Naked DllMain in win32_threads.c (boehm-gc)

Boehm, Hans
Tue Nov 19 17:32:00 GMT 2002

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

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.


More information about the Java mailing list