Re: Compiling GLPK with stdcall calling convention

Hello Andrew,

thank you for adopting the change. I will now start testing.

I think the stdcall DLL should not be called glpk_4_61.dll.
We could call it glpk_4_61_stdcall.dll instead.
This way the user is sure which calling convention the selected DLL is
using.

When GLPK 4.61 is released I will add the stdcall DLL to GLPK for Windows.

Best regards

Heinrich Schuchardt

On 01/08/2017 04:14 PM, Andrew Makhorin wrote:
> Hi Heinrich,
> 
> Thank you for your efforts.
> 
>> for Windows 32 two different calling conventions are used: __cdecl and
>> __stdcall.
>>
>> To use GLPK in conjunction with 32bit LibreOffice (or OpenOffice) Basic
>> it is necessary to compile the GLPK library with __stdcall.
>>
>> Compilation with __stdcall can be achieved by using the /Gz compiler
>> option for Visual Studio Express C++.
>>
>> Unfortunately this is not enough. All functions passed to qsort must use
>> the __cdecl calling convention.
> 
> I'd like just to know why MSVC developers didn't provide a stdcall
> version of the C lib. 
> 
>>
>> On Github I have set up a repository with a patched GLPK 4.60 which
>> allows both compiling with __cdecl and with __stdcall:
>> https://github.com/xypron/glpk/tree/glpk-4.60-stdcall
>>
>> The essential patch is
>> https://github.com/xypron/glpk/commit/471b8ee233da57391b0f4401380c0405f7ab2455
>>
>> It adds a symbol CDECL that is defined in config.h and applied to the
>> relevant comparison functions.
>>
>> I have also added a Makefile and build batch file but these are not
>> essential.
>>
>> Could you, please, consider adding this CDECL symbol to GLPK 4.61.
> 
> Done. Please see
> http://sourceforge.net/projects/noumenon/files/tmp/
> (Note that this is *not* an official release.)
> 
> To avoid defining some macros (i.e. CDECL) on compiling glpk on a
> platform other than GNU/Linux and MS Windows I made the changes in the
> following way:
> 
> #ifndef __WOE__
> int foo(...
> #else
> int __cdecl foo(...
> #endif
> 
> It is always possible to define __cdecl as an empty token sequence, so
> there should be no problem I hope.
> 
> Please check the package with VC10. (I've got only VC9.)
> 
> 
> Best regards,
> 
> Andrew Makhorin
> 
>