help-glpk
[Top][All Lists]
Advanced

[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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]