Compiling and testing Winboard development versions

[lantonov]

After replacing inline int with __inline int in lines 90 and 102 of parser.c, I get:

Code: Select all

C:\Mingw\xboard-c7c73ac\winboard>nmake /f makefile.ms

Microsoft (R) Program Maintenance Utility Version 10.00.30319.01
Copyright (C) Microsoft Corporation.  All rights reserved.

parser.c
wclipbrd.c
wedittags.c
wengineoutput.c
wevalgraph.c
wgamelist.c
whistory.c
history.c
winboard.c
wlayout.c
woptions.c
wsnap.c
wsockerr.c
help.c
wsettings.c
wchat.c
engineoutput.c
evalgraph.c
Microsoft (R) Windows (R) Resource Compiler Version 6.1.7600.16385
Copyright (C) Microsoft Corporation.  All rights reserved.

winboard.rc(505) : warning RC2182 : duplicate dialog control ID 1354
        "c:\program files\help workshop\hcrtf.exe" -xn winboard.hpj
Microsoft (R) Help Compiler
HCRTF 4.03.0002
Copyright (c) Microsoft Corp 1990 - 1995. All rights reserved.
winboard.hpj
    HC3096: Warning: topic #1 of C:\Mingw\xboard-c7c73ac\winboard\winboard.rtf :

        The font name "Franklin Gothic Medium Cond Greek" is longer than 31 char
acters.
    HC3096: Warning: topic #1 of C:\Mingw\xboard-c7c73ac\winboard\winboard.rtf :

        The font name "Franklin Gothic Medium Cond Baltic" is longer than 31 cha
racters.
    HC3096: Warning: topic #1 of C:\Mingw\xboard-c7c73ac\winboard\winboard.rtf :

        The font name "Franklin Gothic Demi Cond Baltic" is longer than 31 chara
cters.
541     Topics
204     Jumps
548     Keywords
0       Bitmaps


Created C:\Mingw\xboard-c7c73ac\winboard\winboard.hlp, 244,553 bytes
Compile time: 0 minutes, 0 seconds
0 notes, 3 warnings
        link -nologo libcmt.lib backend.obj book.obj gamelist.obj lists.obj move
s.obj pgntags.obj uci.obj zippy.obj parser.obj wclipbrd.obj wedittags.obj wengin
eoutput.obj wevalgraph.obj wgamelist.obj whistory.obj history.obj winboard.obj w
layout.obj woptions.obj wsnap.obj wsockerr.obj help.obj wsettings.obj wchat.obj
engineoutput.obj evalgraph.obj wsock32.lib comctl32.lib winmm.lib shell32.lib ol
dnames.lib kernel32.lib advapi32.lib user32.lib gdi32.lib comdlg32.lib winboard.
res -out:winboard.exe
LINK : fatal error LNK1123: failure during conversion to COFF: file invalid or c
orrupt
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 10.0\VC\BI
N\link.EXE"' : return code '0x463'
Stop.

[lantonov]

Seems that above linker error comes from duplicate cvtres.exe in my compiler install. Ignore above until I fix this.

[H.G.Muller]

It seems to choke on the 'inline' keyword, which is C99 standard (but was already a GNU extension to C before that). Either you would have to tell MSVS to use the C99 standard somehow (with some extra flag appended to CFLAGS in the makefile?), or it does not implement 'inline' functions at all. In the latter case simply deleting the 'inline' qualifiers from parser.c would be the only recourse.

[Edit] Our last messages crossed. If MSVS only understands __inline, I guess I should make it a macro INLINE that would be #defined as either 'inline' or '__inline' depending on an #ifdef MSVCVER.

[lantonov]

After renaming cvtres.exe to cvtresold.exe in my VS 2010 install (I have a newer cvtres.exe in Microsoft.NET subdir), I get:

Code: Select all

C:\Mingw\xboard-c7c73ac\winboard>nmake /f makefile.ms

Microsoft (R) Program Maintenance Utility Version 10.00.30319.01
Copyright (C) Microsoft Corporation.  All rights reserved.

        link -nologo libcmt.lib backend.obj book.obj gamelist.obj lists.obj move
s.obj pgntags.obj uci.obj zippy.obj parser.obj wclipbrd.obj wedittags.obj wengin
eoutput.obj wevalgraph.obj wgamelist.obj whistory.obj history.obj winboard.obj w
layout.obj woptions.obj wsnap.obj wsockerr.obj help.obj wsettings.obj wchat.obj
engineoutput.obj evalgraph.obj wsock32.lib comctl32.lib winmm.lib shell32.lib ol
dnames.lib kernel32.lib advapi32.lib user32.lib gdi32.lib comdlg32.lib winboard.
res -out:winboard.exe
book.obj : error LNK2019: unresolved external symbol _snprintf referenced in fun
ction _MovesToText
winboard.obj : error LNK2019: unresolved external symbol _strcasecmp referenced
in function _ParseArgs
winboard.exe : fatal error LNK1120: 2 unresolved externals
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 10.0\VC\BI
N\link.EXE"' : return code '0x460'
Stop.

[lantonov]

I get the same output as above if I add to parser.c

Code: Select all

#ifdef _MSC_VER
#  define INLINE __inline
#else
#  define INLINE inline
#endif


and change inline to INLINE in the 2 places.

[lantonov]

From what I read about linker error LNK2019, it is probably connected with the earlier warning C4113.

[H.G.Muller]

No, this is not connected to any warnings. They are independent errors, because in the MSVS libraries apparently some standard functions are not available that are from the GNU libraries. For strcasecmp this is easily solved, as a function StrCaseCmp, which does the same, is already declared in backend.c. So just capitalize it.

That snprintf only draws an error from book.c is really weird, because I think it is used all over the place in other files. Perhaps it is in another library, which we fail to mention in the linker flags.

[lantonov]

I'll try to reference other libraries then. I wonder if this might not be in the inlined functions. They say that one of the reasons for LNK2019 error is that inlined functions are in a .c (.cpp) but they should be in a header file.

[H.G.Muller]

This seems to be a tough problem. Some Googling reveals that MicroSoft does not support snprintf at all. A work-around is suggested, for instance, here: http://stackoverflow.com/questions/2915 ... tudio-2010 . But it is quite complex.

[lantonov]

StrCaseCmp is properly capitalised in backend.c. Changing it to strcasecmp or _strcasecmp makes no difference in the output.

[lantonov]

In backend.h, line 233 we have #define StrCaseCmp Stricmp. I read that the MSVC function is stricmp (with small s). Changing it there to stricmp does nothing.

[H.G.Muller]

This all is a bit inconsistent and messy. In backend.c we define our own function StrCaseCmp(). The #define of StrCaseCmp is thus useless: it replaces the word StrCaseCmp by something else everywhere in the source, also in the definition, so it remains our own function, no matter what name we give it. What would make a differerence was #define strcasecmp StrCaseCmp . But as strcasecmp only appears in three places (in args.h), we might as well directly substitute it by StrCaseCmp.

The unavailability of snprintf is very annoying, though. At one point Arun substituted all occurrences of sprintf by snprintf for safety reasons, and this apparently thoroughly broke compatibility with MSVS.

[lantonov]

Replacing strcasecmp in arg.h (5 occurences) solved the _strcasecmp linker problem but the _snprintf problem remained.

[lantonov]

I solved the problem. In book.c, lines 724 and 725 snprintf is changed to _snprintf. Compiled normally - 1589 kb.

[lantonov]

Lines 57-62 of book.c became

Code: Select all

#ifdef _MSC_VER
#  define U64(u) (u##ui64)
#  define snprintf _snprintf
#else
#  define U64(u) (u##ULL)
#endif

and compiles in MSVS.

[lantonov]

Now trying to compile the latest Polyglot dev version with MSVS

Code: Select all

C:\Mingw\polyglot-8810e7e>nmake /f makefile.ms

Microsoft (R) Program Maintenance Utility Version 10.00.30319.01
Copyright (C) Microsoft Corporation.  All rights reserved.

attack.c
board.c
book.c
book_make.c
book_merge.c
colour.c
engine.c
epd.c
fen.c
game.c
gui.c
hash.c
io.c
line.c
list.c
main.c
c:\mingw\polyglot-8810e7e\main.c(254) : warning C4716: 'wb_select' : must return
 a value
mainloop.c
move.c
move_do.c
move_gen.c
move_legal.c
option.c
parse.c
pgn.c
piece.c
pipex_win32.c
pipex_posix.c
random.c
san.c
search.c
square.c
uci.c
uci2uci.c
util.c
xboard2uci.c
        link -nologo libcmt.lib attack.obj board.obj book.obj book_make.obj book
_merge.obj colour.obj engine.obj epd.obj fen.obj game.obj gui.obj hash.obj io.ob
j line.obj list.obj main.obj mainloop.obj move.obj move_do.obj move_gen.obj move
_legal.obj option.obj parse.obj pgn.obj piece.obj pipex_win32.obj pipex_posix.ob
j random.obj san.obj search.obj square.obj uci.obj uci2uci.obj util.obj xboard2u
ci.obj oldnames.lib -out:polyglot.exe
main.obj : error LNK2019: unresolved external symbol _ini_disp referenced in fun
ction _main
main.obj : error LNK2019: unresolved external symbol _ini_insert referenced in f
unction _main
main.obj : error LNK2019: unresolved external symbol _ini_next referenced in fun
ction _main
option.obj : error LNK2001: unresolved external symbol _ini_next
main.obj : error LNK2019: unresolved external symbol _ini_start_iter referenced
in function _main
option.obj : error LNK2001: unresolved external symbol _ini_start_iter
main.obj : error LNK2019: unresolved external symbol _ini_find referenced in fun
ction _main
main.obj : error LNK2019: unresolved external symbol _ini_parse referenced in fu
nction _main
main.obj : error LNK2019: unresolved external symbol _ini_init referenced in fun
ction _main
main.obj : error LNK2019: unresolved external symbol _ini_line_parse referenced
in function _parse_args
main.obj : error LNK2019: unresolved external symbol _ini_insert_ex referenced i
n function _parse_args
main.obj : error LNK2019: unresolved external symbol _ini_specials referenced in
 function _write_ini
polyglot.exe : fatal error LNK1120: 10 unresolved externals
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 10.0\VC\BI
N\link.EXE"' : return code '0x460'
Stop.

Compiling with mingw goes fine with some warnings, mostly about unused definitions.

[H.G.Muller]

All those are functions in ini.c. So it seems that ini.c is missing from amongst the sources in makefile.ms, but not in makefile.gcc.

[lantonov]

All those are functions in ini.c. So it seems that ini.c is missing from amongst the sources in makefile.ms, but not in makefile.gcc.

That's right. Solution seems straightforward.

[lantonov]

Yes, this was the problem. The MSVS compile is larger than gcc compile - 221 kb vs 151 kb.

[H.G.Muller]

I was puzzled why the snprinf errors occurred only in book.c, while we literally use it hundreds of times elsewhere. Turns out this problem was detected and fixed before (in v4.5.1, I found that in the SHORTLOG when using "grep snprintf *"), by adding the conditionally required #define snprintf _snprintf to winboard/config.c. So the real problem was that config.h was not #included in book.c, as it should have been!

I now added the #define of inline also in winboard/config.h, which was the logical place for it (under the same #ifdef _MSC_VER).