[openib-general] [PATCH 1/3 v2] osm: Changes for windows compatability

[Yevgeny Kliteynik]

Michael S. Tsirkin wrote:
>> Hi Hal.
>>
>> Fixing windows compilation problems
>> [V2 - Previous patch had an error]
> 
> I don't think "fixing windows compilation" is a real log description.
> What kind of errors? Isn't there a better fix?
> 
>> Signed-off-by: Yevgeny Kliteynik <kliteyn at dev.mellanox.co.il>
>> ---
>>  osm/include/iba/ib_types.h |    2 ++
>>  1 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/osm/include/iba/ib_types.h b/osm/include/iba/ib_types.h
>> index 723e8b9..ec65b64 100644
>> --- a/osm/include/iba/ib_types.h
>> +++ b/osm/include/iba/ib_types.h
>> @@ -59,9 +59,10 @@ BEGIN_C_DECLS
>>           #define OSM_EXPORT	__declspec(dllimport)
>>      #endif
>>      #define OSM_API __stdcall
>> +    #define OSM_CDECL __cdecl
>>  #else
>>      #define OSM_EXPORT	extern
>>      #define OSM_API
>> +    #define OSM_CDECL
>>      #define __ptr64
>>  #endif
>  
> Why is this necessary at all?
> http://msdn2.microsoft.com/en-us/library/zkwh89ks.aspx
> 	Microsoft Specific
> 	This is the default calling convention for C and C++ programs.
> In other words it's the default, you don't have to declare it.
> 
> 	Place the __cdecl modifier before a variable or a function name. Because the C
> 	naming and calling conventions are the default, the only time you need to use
> 	__cdecl is when you have specified the /Gz (stdcall) or /Gr (fastcall) compiler
> 	option. The /Gd compiler option forces the __cdecl calling convention.
> 
> So why are you compiling with /Gz, after the code is already littered with
> OSM_API? And why is OSM_API necessary?

I did saw that __cdecl is default on windows. However, the compiler complained
about a certain function (more specifically - about a comparison function that
is supplied as an argument to qsort() function) that it's defined as __stdcall 
instead of __cdecl. As you say, it's probably because of compilation flag - I 
didn't investigate this issue.

> It seems to me the right thing might be to remove all of OSM_API/OSM_CDECL
> from code, and just build everything on windows with consistent compiler flags.

I'll check with the windows guys why do we have such compilation flag (assuming we 
do have it), and whether it can be removed.

-- Yevgeny