[Gc] Re: DLL_EXPORT vs GC_DLL (MinGW/Cygwin)
ivmai at mail.ru
Tue Mar 6 11:15:23 PST 2012
06 03 2012, 22:35 Kai Tietz <ktietz70 at googlemail.com>:
> 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.
Thank you. I've done like this and applied your patch.
> Thanks and regards,
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc