From: Eli Z. <el...@gn...> - 2013-05-22 15:42:16
|
> Date: Tue, 21 May 2013 17:40:16 -0400 > From: Earnie Boyd <ea...@us...> > > I've an issue[1] I'm trying to resolve which is quite complicated due > to the fact that MinGW supports legacy MSVCRT.DLL while trying to be > useful to the newest versions. These functions needed for when the > macro _USE_32BIT_TIME_T is defined are only available in MSVCRT.DLL > beginning with Vista. They exist in MSVCR80.DLL but we all know the > issues of mixing runtime DLL. I've added the issues to the ticket > below which are quite involved. My question here is should the > libmsvcrt.a import library contain the newest members of the Windows > OS family functions which would cause an incompatibility issue at > runtime if someone uses a function not available on previous OS > versions? Or should we leave the newer functions out of libmsvcrt.a > import library and leave it up to the user to resolve the import? One > way the user can resolve the import is to directly reference the > MSVCRT.DLL during the link phase rather than using the import library. > Another would be for the user to add his functions to the > msvcrt.def.in file and build the runtime libraries from source. What > do the MinGW users desire, runtime incompatibility or a plan to work > through the linker issues? Does anyone have any bright ideas on the > issue? I'm sorry, but I'm not sure I understand the issue completely. As I understand it, _USE_32BIT_TIME_T exists to force use of 32-bit time_t type, where the default is 64-bit. It is a compile-time thing, so it probably only works as long as the program is statically linked to the appropriate library, or not used on a system that doesn't have an msvcrt.dll with the new functions. Is that correct? If the above is correct, then what are your goals? Do you want a 64-bit time_t or do you want a 32-bit time_t (or both)? |