Re: WIN-02: get boehm-gc autodetect if it is compiled as a DLL

[Adam Megacz <patches at lists dot megacz dot com>]

"Boehm, Hans" <hans_boehm@hp.com> writes:
> I'm not sure the first part of this does much, though it may be a minor
> improvement over what's there.  The collector currently provides win32
> thread support only if the GC is built as a DLL, since it relies on the DLL
> attach messages to find out about thread creations.  (For gcj, there are
> probably other possible solutions; I'm not sure exactly what you ended up
> doing.)  Thus GC_WIN32_THREADS normally implies the collector is built as a
> DLL.  But the converse shouldn't necessarily be true.

Interesting -- why does the GC need to know about thread creation? Is
that so that it can scan each thread's stack?

I'm interested in supporting threads in statically linked gcj
binaries; could we add a way for libgcj's java.lang.Thread to notify
boehm-gc when threads are created? If you let me know what function to
call (I assume it should be called from the new thread's context), I
will insert the call in win32's natThread.cc.


> What are the semantics of _DLL?  With some of the Microsoft tools, I thought
> that's sometimes set even if you're just linking against a dynamic libc
> etc.?  That's the reason for the funny GC_NOT_DLL tests.  I didn't think it
> was set only if you're building a DLL.  (If it were, the dllimport side of
> this wouldn't work.)

Perhaps my assumptions about the semantics work only on gcc. We could
replace "defined(_DLL)" with "defined(_DLL) && defined(__GNUC__)".


> Should the first test just be
> 
> #if defined(__MINGW32__) && defined(_DLL) && !defined(GC_NOT_DLL)

Yes, that should work.


> I don't understand the second part of the patch.  At a minimum, the second
> test on _DLL is redundant.  And this should only be relevant for the Digital
> Mars or MS compilers?

Whoops; I didn't understand what defined(DMC) meant. Yes, please
ignore the second hunk of my patch.

  - a