Re: [Bug-XBoard] Xboard-hgbranch-master: Texture on the fly loading bug

[h . g . muller]

Op Do, 3 maart, 2016 3:01 am schreef Joshua Pettus:
>
> At least there is the html version of the menu or does that not work?
>
The current menu does not have separate items for old-style help and html
help, but counts on starting of the old-style help to fail before it
launches the html help. When Windows contains a dummy old-style
helpWinBoard will start that successfully, and thus never get to starting
the html help, but the user only gets to see an apology for that the help
is not working. If they would directly click the .chm file in the WinBoard
folder the html help would work fine.

Perhaps there should be separate items for html and old-style help.
Currently there are separate items for the help index and contents, and
help-about-help, a distinction that is only meaningful for old-style help
anyway. The binary WinBoard distribution also contains a tutorial in the
docs/tutorial folder, which can be viewed with the web browser. Perhaps we
should have a menu item for launching that in a browser, because I don't
think anyone ever found it. We could also have items that launch a browser
for on-line info, as we have in XBoard.

>
> I tried giving the branch a compile and unfortunately hit a snag.  Once
> it got to building the binary, I got a load of undefined symbols.  Is
> there a file that is missing?  There were so many i put it in a text
> file.

These are all symbols from the XBoard front-end, which is not surprising,
as the calls occur in dialogs.c, which is itself only part of the XBoard
front-end. It seems like you are using a Makefile for XBoard. Are you sure
you were builing in the winboard sub-folder? Beware that building WinBoard
runs into trouble when there exists a config.h (produced by running
./configure) in the root folder of the source tart ball, as the compiler
apparently prefers to use that over the config.h in the winboard folder.
(It has to look in both for .h files, to be able to #include both the
common .h files and the WinBoard-specific ones; a -I .. compiler argument
forces it to do so.)

After my troubles with removal of Cygwin by AVG anti-virus I managed to
install a dedicated MinGW compiler that can be invoked from a Windows
command prompt. It did not seem to include a 'make' command, though, but I
managed to build a winboard.exe with a changed winboard.c by entering the
compile and link commands by hand. Later I discovered that it is also
possible to install a more elaborate MinGW distro called MSYS, and I tried
the 64-bit version of this (next to an undamaged 32-bit Cygwin) on my
desktop computer. This MSYS seems to be a Cygwin equivalent, with its own
terminal boxes that provide aLinux-like command prompt, and I could
produce 64-bit .exe with it (tested on connect.exe).

Perhaps we should switch to using that as a platform for WinBoard, rather
than Cygwin. The current winboard/Makefile.gcc only works with obsolete
Cygwins, that still use gcc 3.3.4 (the last one that supported the
-mno-cygwin option), while current Cygwin versions have gcc 5.0.3. So it
seems high time to do something. Adding a separate Makefile.msys seems a
good first step. But I would prefer to continue 32-bit binaries for
WinBoard, as they would run on both architectures.

H.G.


>
> Regards,
> Josh
>
>
>
>