[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Help-glpk] Re: Compilation problem
From: |
Vasily Zatsepin |
Subject: |
[Help-glpk] Re: Compilation problem |
Date: |
Sun, 23 Sep 2007 23:31:56 +0300 |
1) Using of _vsnprintf instead of vsnprintf causes no probs
by building of GLPSOL executable in any of 5 available to me compilers.
2) Here are quick test results of solving CRYPTO.MOD under Windows 98SE
(CPU 333 MHz) with GLPSOL.EXE's built
for Win32 with Visual C 6.0 - 21 s;
Borland C/C++ 5.51 - 30 s;
Dev-CPP - 36 s;
Digital Mars C/C++ - 29 s;
OpenWatcom C/C++ - 16 s;
for DOS32 with Digital Mars C/C++ - 48 s;
OpenWatcom C/C++ - 14 s (CauseWay DOS extender);
OpenWatcom C/C++ - 15 s (DOS4G DOS extender).
Regards,
Vasily Zatsepin
On Sat, 22 Sep 2007 13:13:20 +0400, Andrew Makhorin wrote:
>> But if we look in LIBC.LIB we'll see all the needed stuff!
>> By the way, this place with vsnprintf is troublesome not only in VC 6.0.
>> For example, Digital Mars C/C++ builds OK for Windows but fails when
>> building for DOS32 with the same error.
>> In DMC libraries
>> SNN.LIB (Win32) contains both vsnprintf.obj and _vsnprintf.obj, but
>> SDX.LIB (DOSX) only _vsnprintf.obj.
>> I'll try to build with _vsnprintf instead of vsnprintf.
> Vsnprintf is included in the ISO C standard; see Section 7.19.6.12 in
> http://www.open-std.org/JTC1/SC22/WG14/www/docs/n843.htm . However, it
> is a relatively new function and may be missing on some platforms (as we
> can see).
> I added a check for vsnprintf in the configure script, and now the choice
> between vsprintf and vsnprintf depends on the macro HAVE_VSNPRINTF. This
> will allow compiling glpk on all non-linux platforms without changes.