[Gc] Re: Re[2]: DLL_EXPORT vs GC_DLL (MinGW/Cygwin)

Kai Tietz ktietz70 at googlemail.com
Tue Mar 6 10:31:58 PST 2012


2012/3/6 Ivan Maidanski <ivmai at mail.ru>:
> Hi Kai,
>
> 06 03 2012, 17:46 Kai Tietz <ktietz70 at googlemail.com>:
>> Hi Ivan,
>>
>> this issue is pretty simple.  The define _DLL is misused.  _DLL is
>> defined on mingw targets if a shared msvcrt.dll is used.  It has
>> nothing to do at all with building a DLL, nor it is wise to use it in
>> user-code.
>>
>> The mingw-w64 defines _DLL as there is no other runtime for it beside
>> the msvcrt.dll version.  By this boehm-gc assumes always happily (even
>> in static version) that it shall decorate for imports if user includes
>> the header. (btw the same would happen for VC, if there wouldn't be an
>> explicit define telling it not do so).
>
> I know this (as I recall we discussed it already together) - I left _DLL -> GC_DLL only for non-GNU compilers (for backward compatibility):
>
> #if defined(_DLL) && !defined(GC_NOT_DLL) && !defined(GC_DLL) \
>        && !defined(__GNUC__)
> # define GC_DLL
> #endif
>
> So, now API func are not decorated unless GC_DLL is explicitly specified (for GCC).
>
>> I rely here on DLL_EXPORT (and if actual boehm-gc is built only!) that
>> declspec dllexport is done.  So the shared version of it as DLL gets
>> the proper exports.
>
> I.e., the only your intention was to export only API functions instead of everyone, right?
>
>>
>> I am a bit curious why it should fail, as mingw supports
>> pseudo-relocations, which solves such issues without flaws.
>
> The failure caused by another thing - BDWGC test (unlike gcc/boehm-gc testsuite) uses GC_print_stats which is a private GC variable in case GC_DLL is not defined. So, in case you define DLL_EXPORT (without GC_DLL) gctest linking fails.
> There are 2 possible solutions:
> 1. try to pass DLL_EXPORT while building tests (I do know how to do it);
> 2. [better] Always define GC_print_stats as a macro (set to VERBOSE) in case of MinGW and Cygwin (regardless whether libgc is static or dynamic).
>
> Regards.

Yes, the 2. approach looks better for me, too.

Thanks and regards,
Kai



More information about the Gc mailing list