Re: [Bug-gnubg] Mingw32 cross-compilation

[Vyacheslav V. Yurkov]

Christian Anthon wrote:
> On Tue, Jan 12, 2010 at 9:28 AM, Vyacheslav V. Yurkov
> <address@hidden> wrote:
>   
> > Christian Anthon wrote:
> >     
>
>   
> > external_l.o:external_l.c:(.text+0x258): undefined reference to `_extlval'
> > external_l.o:external_l.c:(.text+0x33f): undefined reference to `_extlval'
> > external_l.o:external_l.c:(.text+0x368): undefined reference to `_extlval'
> > external_l.o:external_l.c:(.text+0x3a9): undefined reference to `_extlval'
> > external_l.o:external_l.c:(.text+0x186b): undefined reference to `_extparse'
> >     
>
> Don't know why this would happen, but these are defined in
> external_y.c. You may try to remove HAVE_SOCKETS config.h and then
> remove the references to external_l/external_y in the makefile.am. But
> remember that config.h gets clobbered next time you run configure.
> Edit configure.in to get rid of HAVE_SOCKETS forever.
>   
I looked over the compilation command again and noticed that there is no 
file external_y.o. So this leads to my original error.
> > gnubg.o:gnubg.c:(.text+0x7b6d): undefined reference to `_CreateMutex'
> >     
>
> You can probably just comment out the line in gnubg.c where it says CreateMute
That helped, thanks.

Finally I sorted out the problem. To compile external_y.y I moved 
definitions of cmdtype and extcmd from external.h to external_y.y.
typedef enum _cmdtype  {
 COMMAND_NONE = 0,    
 COMMAND_FIBSBOARD = 1,
 COMMAND_EVALUATION = 2
} cmdtype;

typedef struct _extcmd {
 cmdtype ct;

 /* evalcontext */
 int nPlies;
 float rNoise;
 int fDeterministic;
 int fCubeful;
 int nReduced;
 int fUsePrune;

 /* fibs board */
 char *szFIBSBoard;
} extcmd;
For some reason they seemed to be undefined for compiler from external.h.

One more note. Files board3d/drawboard3d.c and board3d/misc3d.c include 
file wglBuffer.h.
The include is done inside #ifdef WIN32 condition directives as
#include "wglbuffer.h"
Since I make cross-compilation in Linux environment file names are 
case-sensitive. So it is preferable to have "wglBuffer.h" instead of 
"wglbuffer.h".

--
Vyacheslav V. Yurkov <address@hidden>     Senior Software Engineer
Norilsk                                         Tel: +79069001870

Software Development Department
Joint Stock Company "Channel-7", ISP