|
From: | Charles Wilson |
Subject: | Re: [3/11] Native MSVC support (msvc-cwrapper) |
Date: | Sat, 21 Jul 2007 06:51:47 -0400 |
User-agent: | Thunderbird 1.5.0.12 (Windows/20070509) |
Peter Rosin wrote:
On Thu, Jul 19, 2007 at 05:47:36PM -0400, Charles Wilson wrote: The cwrapper has two targets (cygwin, mingw), I'm adding a third (msvc). Both the previous targets has stat as stat, cygwin doesn't have _stat and msvc doesn't have stat (unless you link with OLDNAMES.LIB).So, going the other way around breaks cygwin (IIRC).
How can it break cygwin? +#ifdef _MSC_VER +# define S_IXUSR _S_IEXEC +# define _stat stat +# ifndef _INTPTR_T_DEFINED +# define intptr_t int +# endif +#endifcygwin does not #define _MSC_VER (nor does mingw, AFAIK). So, the only thing that matters here, is:
(1) the cwrapper code invokes stat(). (2) on cygwin this works.(3) on mingw this works, because -lmoldnames is linked in via libgcc's dependencies in the spec file. At least, for now. (4) on msvc this is broken, because the only thing exported by msvcrt.dll is _stat.
Therefore, on msvc only, we want the cwrapper to call _stat() instead of stat(). Thus:
#ifdef _MSC_VER # define stat _stat #endif
But I guess mingw could drop stat at some point as well (and require -loldnames) in order to match the MS libc. I think mingw has _stat already.
Yes, mingw has _stat via the libmsvcrt.a import library. But right now, it automatically gets stat() via libmoldnames, so there's no need to change anything.
Should I commit as is?
Since the only line in dispute is guarded by _MSC_VER, I believe that is up to you. Whether that line is right or wrong, it won't break mingw nor cygwin. But you should test under both MSVS-2003 and MSVS-2005, to make sure you've got that particular line correct.
-- Chuck
[Prev in Thread] | Current Thread | [Next in Thread] |