Winboard Forum

Hi,

I was looking at PSWBTM. In the readme you said you could not get in to work on Linux as "xboard is quite different from Winboard".

Do you remember what the issues were. Perhaps they can be fixed.

Regards,
Michel

I am sure it is very easy to fix. But the main problem is that I cannot even run PSWBTM under Linux. When I load the executable from Pradu´s site it does not run under my Linux, and complains about missing run/time libraries, the required (obsolete) versions are unoptainable. If I load the source, I cannot compile it under Linux because it is missing the compile-time libraries that are unobtainable.

Without a working PSWBTM I cannot pinpoint the cause of the problem (which seems to be that the engines refuse to start, and immediately exit in stead), and fix it in WinBoard. There would be little point anyway, if we don't have a running PSWBTM...

I am sure it is very easy to fix. But the main problem is that I cannot even run PSWBTM under Linux. When I load the executable from Pradu´s site it does not run under my Linux, and complains about missing run/time libraries, the required (obsolete) versions are unoptainable. If I load the source, I cannot compile it under Linux because it is missing the compile-time libraries that are unobtainable.

Ok I'll have a look (not today though as I am busy).

OK. What I know of it (after we fixed it such that PSWBTM was only invoking xboard with command-line options it knew) is this:

When the xboard process spawn by PSWBTM forks to create an engine process, and then executes the engine, the engine seems to initialize allright, but then suddenly exits. Most likely this is triggered by the engine starting to read or write from a broken pipe. (This was reported to me by Pradu, whose Linux seems to be the only one capable of compiling and running PSWBTM.)

POST DELETED

(This was reported to me by Pradu, whose Linux seems to be the only one capable of compiling and running PSWBTM.)

After looking at the "official" source tree very quickly it seems there is only a Makefile.win, so either Pradu sends his Linux makefile to you, or you adapt Makefile.win (should be quite easy since it is already based on gcc/g++).

The only issue might be that it is based on wxWidgets which I guess you have to download and build for your own Linux. Maybe the wxX11 port is the one that is required, for which the build shall be prepared (according to the docs, see the very end of "wx.pdf" which can be downloaded from SourceForge together with other PDF docs) by "configure --with-x11 --with-universal".

My 0,0002 ct

Sven

Michel wrote:I wonder if there is not a license problem with PSWBTM. It seems wxWindows is GPL according to this page http://docs.wxwidgets.org/stable/wx_wxl ... #wxlicense.
By the nature of the GPL the license of PSWBTM should then also be GPL compatible,

I have the feeling that the license

http://pradu.us/home/cc/PSWBTM/

is not GPL compatible. Item 2 is the cuprit

2. Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software.

I think it was such a clause that made the original Qt non-GPL compatible.

EDIT: I am not trying to be obnoxious, but in the open source world license issues are taken very seriously.

For the binary package; in the licence (http://www.opensource.org/licenses/wxwindows.php) it says

Code: Select all

 2. The exception is that you may use, copy, link, modify and distribute under the user's own terms, binary object code versions of works based on the Library.

I do not distribute wxWidgets source code along with the source distribution either. Therefore I can place whatever license I want on the source code as well.

2. The exception is that you may use, copy, link, modify and distribute under the user's own terms, binary object code versions of works based on the Library.

Yes I had not noticed that. Sorry.

Sven Schüle wrote:

(This was reported to me by Pradu, whose Linux seems to be the only one capable of compiling and running PSWBTM.)

After looking at the "official" source tree very quickly it seems there is only a Makefile.win, so either Pradu sends his Linux makefile to you, or you adapt Makefile.win (should be quite easy since it is already based on gcc/g++).

The only issue might be that it is based on wxWidgets which I guess you have to download and build for your own Linux. Maybe the wxX11 port is the one that is required, for which the build shall be prepared (according to the docs, see the very end of "wx.pdf" which can be downloaded from SourceForge together with other PDF docs) by "configure --with-x11 --with-universal".

My 0,0002 ct

Sven

Yeah I use the following Linux makefile:

Code: Select all

WX_CONFIG := wx-config

PROGRAM = PSWBTMApp

FLAGS = -DwxUSE_UNICODE=0 -Bstatic -D_XBOARD
LFLAGS = -DwxUSE_UNICODE=0 -Bstatic

OBJECTS = $(PROGRAM).o Configuration.o Engine.o EngineList.o EngineManager.o \
NewTournament.o Pairing.o PSWBTMFrm.o Tournament.o \
UpdateInfoEvt.o

CXX = $(shell $(WX_CONFIG) --cxx)

.SUFFIXES:   .o .cpp

.cpp.o :
   $(CXX) -c `$(WX_CONFIG) --cxxflags` $(FLAGS) -o $@ $<

all:    $(PROGRAM)

$(PROGRAM):   $(OBJECTS)
   $(CXX) -o $(PROGRAM) $(OBJECTS) $(LFLAGS) `$(WX_CONFIG) --libs`

clean:
   rm -f *.o $(PROGRAM)


At least I think I understand the compilation issue. PSWBTM uses non-unicode strings
(the good old "...."). Now it seems the recent wxWindows libraries that come with
Ubuntu no longer support the non-unicode functions (at least I did not find out how
to make them work). As a result you get errors like

undefined reference to `wxString::Format(char const*, ...)

because a function of that signature is no longer in the library.

If you delete -DwxUSE_UNICODE=0 from the makefile you get compilation errors

PSWBTMApp.cpp:21: error: no matching function for call to ‘wxString::Format(const char [7])’
/usr/include/wx-2.8/wx/string.h:1208: note: candidates are: static wxString wxString::Format(const wxChar*, ...)


So do we have to convert PSWBTM to unicode (a trivial but tedious fix) or is there
another solution (I do not know wxWindows very well)?


Michel

Michel wrote:At least I think I understand the compilation issue. PSWBTM uses non-unicode strings
(the good old "...."). Now it seems the recent wxWindows libraries that come with
Ubuntu no longer support the non-unicode functions (at least I did not find out how
to make them work). As a result you get errors like

undefined reference to `wxString::Format(char const*, ...)

because a function of that signature is no longer in the library.

If you delete -DwxUSE_UNICODE=0 from the makefile you get compilation errors

PSWBTMApp.cpp:21: error: no matching function for call to ‘wxString::Format(const char [7])’
/usr/include/wx-2.8/wx/string.h:1208: note: candidates are: static wxString wxString::Format(const wxChar*, ...)


So do we have to convert PSWBTM to unicode (a trivial but tedious fix) or is there
another solution (I do not know wxWindows very well)?


Michel

Indeed I'm using an older wxWidgets to compile (gtk2-ansi-release-2.8.4.0) because I've been too lazy to upgrade. Type wx-config --unicode=no and try to compile again with your version of wxWidgets. I would be surprised if there is no longer any ANSI support in wxWidgets. If this doesn't work either, I'll try to find out what the problem is this weekend.

wx-config --unicode=no gives

Code: Select all

Warning: No config found to match: /usr/bin/wx-config --unicode=no
           in /usr/lib/wx/config
  If you require this configuration, please install the desired
  library build.

It seems Ubuntu 8.04 does not contain a non unicode build of wxWindows. Perhaps
this is natural as Ubuntu is an international distribution. I guess users could compile
their own non-unicode version of wxWindows but this is not so convenient.

If this doesn't work either, I'll try to find out what the problem is this weekend.

Thanks! I was about half way through with translating PSWBTM into unicode, but I'll wait
with what you come up with.

EDIT: Here are the instructions on how to write wxWindows programs so that they work both on ansi builds and on unicode builds

http://docs.wxwidgets.org/stable/wx_uni ... ml#unicode


Regards,
Michel

I made a quick and dirty translation into unicode for testing. The GUI now comes up fine, but some things do not yet work correctly.

Pradu: in which source file is xboard started?

EDIT: actually it seems the problems I am having are due to the configuration options not
being saved properly. I need to debug this first.

EDIT2: Ok the configuration problem seems to be fixed. Now some real debugging....

EDIT3: Ok now I am at the point we were before. xboard starts but cannot fire up the engine.


Regards,
Michel

It seems that there is simply a fundamental limitation of wxExecute under Linux.
Look at the following trivial program

Code: Select all

#include "wx/wx.h"

int main(){
        wxExecute(wxT("xboard"));
}

and compile it with

Code: Select all

g++ test.c -o test `wx-config --cflags` `wx-config --libs`

If you execute ./test then xboard starts succesfully but you get

Code: Select all

Error: first chess program (gnuchessx) exited unexpectely

Executing xboard directly from the command line works fine.

Michel,

to further analyze why your example program exits unexpectedly you could try tracking all system calls and their results by calling something like "strace -f ./test >strace.log 2>&1" and watch out for any anomalies in "strace.log". If "strace" is not in your PATH then maybe it's /sbin/strace or /usr/sbin/strace. "-f" includes child processes.

Sven

For those who want to play: here is an experimental unicode version of PSWBTM.

http://alpha.uhasselt.be/Research/Algeb ... ode.tar.gz

It should compile on a modern Linux.

Of course there will still be bugs, but they should be relatively trivial. And of course it fails spectacularly in its main function, which is to start xboard ;(

I hope I have not introduced major memory leaks. My vision of C++ memory management is somewhat hazy.

to further analyze why your example program exits unexpectedly you could try tracking all system calls and their results by calling something like "strace -f ./test >strace.log 2>&1" and watch out for any anomalies in "strace.log". If "strace" is not in your PATH then maybe it's /sbin/strace or /usr/sbin/strace. "-f" includes child processes.

Thanks that a good idea!

Code: Select all

#include "wx/wx.h"

int main(){
        wxExecute(wxT("xboard"));
}

I wrote to the wxWidgets mailing list. The issue seems to be that wxExecute in ASYNC mode closes all unused file descriptors in the child. Although it is not clear yet why this would give a problem for xboard.

The above example works fine in SYNC mode which does not close file descriptors.

Regards,
Michel

Ok. I compiled my own version of wxWidgets and commented out this section
in utilsunx.cpp/wxExecute

Code: Select all

        // These lines close the open file descriptors to to avoid any
        // input/output which might block the process or irritate the user. If
        // one wants proper IO for the subprocess, the right thing to do is to
        // start an xterm executing it.
        if ( !(flags & wxEXEC_SYNC) )
        {
            // FD_SETSIZE is unsigned under BSD, signed under other platforms
            // so we need a cast to avoid warnings on all platforms
            for ( int fd = 0; fd < (int)FD_SETSIZE; fd++ )
            {
                if ( fd == pipeIn[wxPipe::Read]
                        || fd == pipeOut[wxPipe::Write]
                        || fd == pipeErr[wxPipe::Write]
                        || traits->IsWriteFDOfEndProcessPipe(execData, fd) )
                {
                    // don't close this one, we still need it
                    continue;
                }

                // leave stderr opened too, it won't do any harm
                if ( fd != STDERR_FILENO )
                    close(fd);
            }
        }
}

Lo and behold all problems disappeared! It seems to me that the above code segment
closes non open file descriptors which perhaps leads to undefined behaviour.

Regards,
Michel

If closing a non-open file descriptor leads to problems, this should be considered a severe Ubuntu bug.

But apart from that, I can't understand what happens here. Engines would inherit any open file descriptors from PSWBTM through xboard, but they are not supposed to use them. Engines use only stdin or stdout (or sometimes log files they open themselves). And xboard is supposed to provide a pipe on these descritors, by creating the pipe, and then using dup2 to copy the pipe descriptors to stdin and stdout, and close the original ones (in the child process that is going to run the engine). xboard does not test if any of these calls fail, though. (Or if the pipes actually work.)

I don't know if you are also set up to mdify and compile xboard. The place to look would be in xboard.c (look for execvp , which is the call that invokes the engine, and is preceeded by the calls to duplicate and close the pipe descriptors) and childio.c (which contains two calls to pipe() to create the pipes, in the routine SetUpChildIO). It would be interesting to see what these routines return, perhaps by writing it to the debug file (and then starting xoard with with -debug), through adding:

if(appData.debugMode) fprintf(debugFP, "call to ...() = %d\n", returnStatus);

for each of the calls.

Hi,

This is really a wxWidgets problem. wxExecute does not work with programs that fork themselves. I verified this independently with ucibench (like xboard, ucibench also starts up a chess engine).

The good news is that I talked to Vadim Zeitlin and this will probably be fixed in a future version of wxWidgets (the fix is deleting the for loop in my last post; one has to verify that this does not break existing programs).

I think in the mean time it might be best to write our own version of wxExecute. However I think one can not take the code directly from wxWidgets and modify it because of the GPL.

If closing a non-open file descriptor leads to problems, this should be considered a severe Ubuntu bug.

I am not sure about this. Closing a non-open file descriptor is definitely something you should not do. But this is all hypothetical. I do not know if the problems are caused by the closing of non-open file descriptors.

Regards,
Michel