Re[4]: [Gc] Win64 GCC support

Ivan Maidanski ivmai at
Mon Jun 29 02:56:30 PDT 2009


NightStrike <nightstrike at> wrote:
> 2009/6/22 Ivan Maidanski <ivmai at>:
> > Could you submit us a patch (fixing your problems in any way you like) which doesn't touch .c/h files?
> Ok.
> I cleaned up the beginning of the file, too:
> Index:
> ...
> +AS_CASE([$host],
> +  [x86_64-*-mingw*],
> +    [AC_DEFINE([GC_NOT_DLL])]
> ...

This is not correct. You shouldn't unconditionally define for GC_NOT_DLL for mingw-w64. The correct way would be:
1. use -DGC_NOT_DLL for building static libraries (--enable-static),
2. use -DGC_BUILD -DGC_DLL for building shared libraries (--enable-shared).

Note that both --enable-static and --enable-shared could be both specified at the same time (so you can't place these macros to CFLAGS or config.h).

Note 2: it should be assumed not to specify both -DGC_NOT_DLL and -DGC_DLL at the same time (for a single target).

Note 3: If none of -DGC_DLL and -DGC_NOT_DLL are not specified (but -DGC_BUILD is still present) then the behavior is controlled by _DLL macro - if _DLL is present then shared lib is built else static one.

IMHO, some of the above things should be changed, so I've prepared a patch (which I'll post this or next week). It would do:
1. handle config.h for GC itself the same way as for libatomics;
2. always define GC_BUILD in private headers (if not defined in build scripts);
3. ignore _DLL and GC_NOT_DLL at build time (but not at use time to be backward compatible);
4. remove GC_BUILD and GC_NOT_DLL from scripts, make files and doc (as they are not needed anymore).

NightStrike <nightstrike at> wrote (today):
> Ping....
Too early for a sending a remainder ;)

> Because of this:
> I think we are once again at a stage where we need this patch.

I've checked the latest mingw-w64 (both x86 and amd64) with GC - it works.
I guess, this would work with configure too provided, for now, you use in the command line something like CFLAGS=-DGC_NOT_DLL ./configure (or use your patched configure version for now).

> Also, Ivan, we still need all of this back-ported to the GCC tree.

I've looked thru the diff between gcj boehm-gc and gc6.8 once more.
As I see, for Windows target only thread registration should be updated in

I try to explain how this (GC_get_stack_base, GC_[un]register_my_thread) should look in a JVM (on any target paltform):

__declspec(thread) int unregister_my_thread_on_detach = 0;

JNI_AttachCurrentThread[AsDaemon] {
  struct GC_stack_base stackbase;
  if (GC_get_stack_base(&stackbase) != GC_SUCCESS)
   abort(); /* can't find out stack base */
  if (GC_register_my_thread(&stackbase) == GC_SUCCESS)
   unregister_my_thread_on_detach = 1;
   /* else GC_DUPLICATE is returned meaning it's already registered by someone else, eg. implicitly */

JNI_DetachCurrentThread {
 if (unregister_my_thread_on_detach)

Hope this helps you.


More information about the Gc mailing list