Hi,
I've been compiling the wine tests with visual studio 2003, and there are a couple errors popping up. One of the errors is that the align modifier is not allowed on function parameters, so most of the test fail to compile with wine's headers because we align most of our data types (AFAICS, I haven't looked through all of our winnt.h):
(from wine/include/winnt.h) typedef unsigned __int64 DECLSPEC_ALIGN(8) ULONGLONG, *PULONGLONG;
Whereas ms' ULONGLONG does not have the align modifier:
(from ms' winnt.h) typedef unsigned __int64 ULONGLONG;
Should we reconcile the difference and remove the align from out types? If not the tests won't compile with vs so I guess the other option would be to #pragma disable that warning. Any ideas?
On Tue, 15 Feb 2005 14:46:51 -0600, James Hawkins truiken@gmail.com wrote:
Hi,
I've been compiling the wine tests with visual studio 2003, and there are a couple errors popping up. One of the errors is that the align modifier is not allowed on function parameters, so most of the test fail to compile with wine's headers because we align most of our data types (AFAICS, I haven't looked through all of our winnt.h):
(from wine/include/winnt.h) typedef unsigned __int64 DECLSPEC_ALIGN(8) ULONGLONG, *PULONGLONG;
Whereas ms' ULONGLONG does not have the align modifier:
(from ms' winnt.h) typedef unsigned __int64 ULONGLONG;
Should we reconcile the difference and remove the align from out types? If not the tests won't compile with vs so I guess the other option would be to #pragma disable that warning. Any ideas?
I forgot to give the link to msdn which contains the documentation of the particular error:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html...
On Tuesday 15 February 2005 21:46, James Hawkins wrote:
Should we reconcile the difference and remove the align from out types? If not the tests won't compile with vs so I guess the other option would be to #pragma disable that warning. Any ideas?
The use of DECLSPEC_ALIGN(8) could be made dependend on which compiler is used. When compiling with GCC we really need the modifier because otherwise it will align 64 bit types to 4 bytes, unlike MSVC, which aligns them to 8 bytes by default.
-Hans
On Tue, 15 Feb 2005 22:09:06 +0100, Hans Leidekker hans@it.vu.nl wrote:
On Tuesday 15 February 2005 21:46, James Hawkins wrote:
Should we reconcile the difference and remove the align from out types? If not the tests won't compile with vs so I guess the other option would be to #pragma disable that warning. Any ideas?
The use of DECLSPEC_ALIGN(8) could be made dependend on which compiler is used. When compiling with GCC we really need the modifier because otherwise it will align 64 bit types to 4 bytes, unlike MSVC, which aligns them to 8 bytes by default.
-Hans
Would something like this work? After I make this change, advapi32 compiles successfully with wine's headers.
#ifndef _ULONGLONG_ #define _ULONGLONG_
#if defined(_MSC_VER) typedef signed __int64 LONGLONG, *PLONGLONG; typedef unsigned __int64 ULONGLONG, *PULONGLONG; #elif defined(__GNUC__) typedef signed __int64 DECLSPEC_ALIGN(8) LONGLONG, *PLONGLONG; typedef unsigned __int64 DECLSPEC_ALIGN(8) ULONGLONG, *PULONGLONG; #endif
#endif
"James Hawkins" truiken@gmail.com wrote:
I've been compiling the wine tests with visual studio 2003, and there are a couple errors popping up. One of the errors is that the align modifier is not allowed on function parameters, so most of the test fail to compile with wine's headers because we align most of our data types (AFAICS, I haven't looked through all of our winnt.h):
(from wine/include/winnt.h) typedef unsigned __int64 DECLSPEC_ALIGN(8) ULONGLONG, *PULONGLONG;
Whereas ms' ULONGLONG does not have the align modifier:
(from ms' winnt.h) typedef unsigned __int64 ULONGLONG;
Should we reconcile the difference and remove the align from out types? If not the tests won't compile with vs so I guess the other option would be to #pragma disable that warning. Any ideas?
I'm compling Wine tests with MSVC and Wine headers on a regular basis when I'm adding new tests or check for breakages. That works fine for me, I don't have any problems with the process.
Here is a sample command line:
cl -W3 -O2 -MD -D_X86_ -Dinline=__inline -I. -I.\include -D__i386__ win.c testlist.c user32.lib gdi32.lib