MoHex is coming!

The Benzene project has released MoHex, the world champion Hex engine. At the bottom of the page they mention plans to play on LG.

I haven't been able to build it yet on my Debian amd64 machine. I posted my woes on the Benzene help forum.

If MoHex is smart enough to find the winning move for white in their screen shot, that would be very strong indeed.

> ./configure --with-fuego-root=/usr/local/bin/fuego ...

> ...

> cc1plus: error: /usr/local/bin/fuego/gtpengine: Not a directory

> cc1plus: error: /usr/local/bin/fuego/smartgame: Not a directory

I don't know anything about this, but the first things I would ask are

Is there a /usr/local/bin/fuego directory? If so, what's in it? Does it contain gtpengine or smartgame subdirectories?

If not, are there gtpengine or smartgame directories somewhere else?

when you built benzene did you remember to issue command 'make install' after 'make'? if not, that's the problem, the files haven't been installed to /usr/local/bin yet.

in my experience it seems unlikely, though not unheard of, that there would be a directory created in /usr/local/bin. you need to find where the fuego directory was installed when you built fuego. its definitely somewhere under /usr/local unless you specified elsewhere.

if it is there, i suspect it could be a permissions problem, in which case try building it again exactly the same way but as 'root'

DJ Bush wrote:

> The Benzene project has released MoHex, the world champion Hex engine.

> At the bottom of the page they mention plans to play on LG.

Great news. Thanks for sharing them.

> If MoHex is smart enough to find the winning move for white in

> their screen shot, that would be very strong indeed.

Can't wait to see it play here.

Ingo.

MG, my mistake was to set the wrong root path to fuego when I ran configure. But now make produces errors with regard to the book directory. I posted again on the help forum.

stickman, I haven't built benzene yet. I'm still stuck on the "make" command, so I didn't get to "make install" yet.

Here's a better link to that help forum.

sorry i meant fuego.

@DJB: Looking at your "better link", my guess is that choice of database is a configuration option, and the error message

../../src/util/HashDB.hpp:15:16: error: db.h: No such file or directory

means that the choice has not been made. I'm looking at a Linux system that has 3 db.h files within /usr/include, namely,

/usr/include/db4.5.20/db.h

/usr/include/db4.6.21/db.h

/usr/include/db4.7.25/db.h

and I'm guessing that the choice among those three versions has to made explicitly, probably with something like --mypreferreddatabase=db4.6.21 on the configuration command line. If there's a README file associated with the configuration or with the build, it may indicate how to indicate your choice.

it says in the README you need to install boost, or possibly you can use "./configure --without-boost" or "--with-boost=no"

also, there is nothing to indicate that the opening book is a separate process, it is likely done automatically.

I could build and run (with hexgui) easily on my machine (ubuntu-10, amd64,

with boost installed). Just follow instructions from benzene/README

(get fuego from svn, benzene from git). Be sure to type

./configure --with-fuego-root=[absolute path to fuego]

the file /usr/include/db.h is from package libdb-dev

Awesome, I am totally excited for the day MoHEx appears on LG.

I installed the libdb-dev package with aptitude.

I missed a paragraph from the README file for benzene:

(NOTE: This current build of Benzene is tested with revision 1163 (circa September 2010). It is possible that in the future the trunk version of fuego can differ drastically from this version. It may be necessary to checkout a branch in the fuego repository created near revision 1163 to get the compile to work, or to checkout revision 1163 itself with the "-r 1163" option to "svn co".)

I went back and added -r 1163 to the svn co command for fuego. Fuego configure and make ran without error. So did configure for benzene, using the correct root path. When I ran the make command for benzene, I got further than I got before, but again errors appeared. See my "better link" above for another console excerpt.

I'm grateful for all your input!

Hi David, it's a long shot, but maybe try compiling without enabling 14x14... all of our tournies are on 11x11, so there's a chance we neglected something there.

I've moved off the Benzene project now (thesis done, now working in Silicon Valley, no spare time) so now there's really only one active developer on our Hex program. Still, I'll definitely let him know there's strong interest on LG for the MoHex player... I believe the LG-playing code is essentially ready, it just needs to be setup and started.

p.s. if memory serves, the position in Benzene's screenshot was taken from an olympiad game (I think 2009?) where both bots kept playing losing moves until our parallel solver intervened.

I upgraded my Debian from 5.0 to 6.0, and finally got error messages that made sense. I installed libboost-all-dev and now it works! I can play against Mohex and Wolve on HexGui. These engines are not as strong as I had hoped, but at least now I am sure no one can beat me by using them :-)

A session report on a loss to Wolve on 11x11 is on Board Game geek. Wolve is much stronger than I realized at first. I was playing MoHex, and the default settings for that engine make it play very quickly. MoHex makes each of its moves within 15 seconds in nearly every case. Wolve, by comparison, takes about 30 minutes total to make all its moves on an 11x11 grid. So, when I figure out how to tell MoHex to play as slowly as Wolve does, it should exhibit even stronger play than Wolve!

Hi David,

Interesting post. I'll also give MoHex/Wolve a try to them when I've time. I agree with your analysis of 1.G2 2.E8 3.H7 4.H6 5.D8 but I think 5. E7 6. E7 is white win due to the parallel ladder trick (do these bots detect it?). On the other hand, 5. I6 6. I5 7. F7 should be black win. Anyway, it seems that it is very easy to blunder, both for humans and computers..

See you!

When comparing the HexGui of benzene project and the HexGui released by me (which are

both based on GoGui, so they are similar, but were developed independently), i noticed one thing:

HexGui 0.9.0 of benzene project uses "swap-pieces" and "swap-sides" the opposite way

than described in this document

http://red-bean.com/sgf/hex.html (sgf Hex standard), which I used also.

Otherwise the two applications and hex engines will be compatible.

Eg:

Wrong Sgf file (by benzene HexGui)

(;AP[HexGui:0.9.0]FF[4]GM[11]SZ[9];B[b1];W[swap-pieces];W[a2];B[c1];W[d1])

(notice this is impossible, b1 swaps onto a2 => 3rd move a2 is illegal)

Corrected:

(;AP[HexGui:0.9.0]FF[4]GM[11]SZ[9];B[b1];W[swap-sides];W[a2];B[c1];W[d1])

(same in gtp stream)

play black b1

play white swap-sides

play white c1

etc... is correct

If you could change this - in the next release, it would be good. So benzene will be

compatible with the "rest of the world" ..

I try to change my HexGui slightly too, and try to make the rest compatible (i need to support both

swap methods in the gui and in the six engine).

Sorry for not reporting it earlier ..

i see there was already some discussion on the benzene-devel mailing list and the problem has been noticed.

However i'm against relabeling "swap-pieces" to "swap-firstpiece", it will change the standard unnecessarily ( http://red-bean.com/sgf/hex.html has been online i guess for five years, i consider it the official sgf standard).

Also, i tested the six engine in benzene-Gui, it roughly works, just as long as there are no swap moves in the game.

Supporting both swap methods in all guis is a good idea, since there are now engines which prefer different swap methodes (and sgf allows both swap methods also).

Does someone know if there is a command to use "dfpn-solver-find-winning" and "dfpn-solve-state" on multi-processor machines? Thank you.

To answer lazy's question, Mohex and Wolve are buggy when the number of threads is set greater than 1. Apparently, that project is in limbo now.

I have a new machine and a new OS, Linux Mint Debian 64 bit. I again have difficulty building benzene, as detailed in this thread. I hope someone here, for example someone named MarleysGhost, might provide a clue once again.

ab, you have a point that the SGF standard WRT Hex has been in place for five years, but I just want to make the observation that in a real game, if one chooses to swap without swapping sides, then only one piece is swapped, and "swap-pieces" is grammatically incorrect. Someone should have picked up on that a long time ago, but no one did. I wonder whom this change would affect, other than yourself, the benzene team (who have all apparently moved on), Ignatius J Rielly (who might not have made any changes yet pertaining to swap in Jhex), Kevin O'Gorman (same), and Richard Malaschitz (who went his own way regarding sgf).

According to this,

Boost filesystem version 2

, versions of Boost since 1.46 have deprecated native_file_string(). I'm not familiar with the details of Boost or benzene's configuration, but you likely can work around the problem by one of the following:

1) Set the compiler flags to use the old Boost interface (according to the documentation this won't work if the version of Boost is 1.48 or later). You want to include "-DBOOST_FILESYSTEM_VERSION=2" in the C++ compiler options. Rerunning the configuration step with

env CPP_FLAGS="-DBOOST_FILE_SYSTEM_VERSION=2" what_you_used_previously_for_configuration

looks like it should work.

2) Modify the source code to replace instances of native_file_string with file_string (I'd also check the Boost documentation to see if those functions are really interchangeable; if they are not, then the source code changes won't be as simple search and replace). I believe src/book/CacheBook.cpp, src/commonengine/Swapcheck.cpp, src/hex/IcePatternSet.cpp, src/hex/VCPattern.cpp, and src/uct/HexUctPolicy.cpp are the only files in benzene 0.9 that use native_file_string.

Ugh, the list of files affected by native_file_string() should be

src/book/CacheBook.cpp
src/commonengine/SwapCheck.cpp
src/hex/IcePatternSet.cpp
src/hex/VCBuilder.cpp
src/hex/VCPattern.cpp
src/uct/HexUctPolicy.cpp

According to http://www.boost.org/doc/libs/1_47_0/libs/filesystem/v3/doc/reference.html

Deprecated functions not available by default; will be supplied if BOOST_FILESYSTEM_DEPRECATED is defined:

const std::string file_string() const {
return native_string(); }
const std::string directory_string() const {
return native_string();
}
const std::string native_file_string() const {
return native_string();
}
const std::string native_directory_string() const {
return native_string();
}
const string_type external_file_string() const {
return native();
}
const string_type external_directory_string() const {
return native();
}

If your version of Boost is 1.47 or something where this still applies, then rebuilding Boost (I have no idea what that entails.) with "BOOST_FILESYSTEM_DEPRECATED defined", which I can only presume means with something like

#define BOOST_FILESYSTEM_DEPRECATED 1

in a header file that will be seen before the precompiler code decides whether to define the above deprecated functions, is one way to get around it.

The better method would be to replace the calls to the deprecated native_file_string() function with calls to the native_string() function, presumably in the six source files that duncecap has found.

Wow, that is an immense help! But I made an earlier mistake. The session log shows I neglected to make the fuego package prior to making benzene. I am using an earlier version as described in the README file with benzene. From the benzene directory,

cd ..
svn co -r 1163 https://fuego.svn.sourceforge.net/svnroot/fuego/trunk fuego
cd fuego
autoreconf -i
./configure --enable-assert --enable-optimize

all of which completed without error. But when I ran make,

...
g++ -DHAVE_CONFIG_H -I. -I.. -pthread -I/usr/include -I../gtpengine -O3 -g -Wall -Wextra -MT libfuego_smartgame_a-SgIncrementalStack.o -MD -MP -MF .deps/libfuego_smartgame_a-SgIncrementalStack.Tpo -c -o libfuego_smartgame_a-SgIncrementalStack.o `test -f 'SgIncrementalStack.cpp' || echo './'`SgIncrementalStack.cpp
In file included from SgBWSet.h:12:0,
from SgIncrementalStack.cpp:10:
SgPointSetUtil.h:68:25: error: reference ‘m_pointSet’ cannot be declared ‘mutable’ [-fpermissive]
make[2]: *** [libfuego_smartgame_a-SgIncrementalStack.o] Error 1
make[2]: Leaving directory `/home/david/games/Hex/Benzene/fuego/smartgame'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/david/games/Hex/Benzene/fuego'
make: *** [all] Error 2
david@achernar:~/games/Hex/Benzene/fuego$

Again I hope for a clue.

You can delete that keyword "mutable" in SgPointSetUtil.h which causes the error. That's what more recent versions of Fuego have.

Martin

Okay, I removed mutable, and that error went away, thank you. I still haven't completed a successful make on fuego yet, which means I haven't even gotten to the benzene mods yet. But I am keeping a log of all my changes and their effects. In

/fuego/go/GoGtpEngine.cpp:408:46:

it complained about an instance on native_file_string(), and when I replaced that with file_string() it still complained. But this is version 3 not version 2. The version 3 list of deprecated names says native_file_string() should be replaced by simply string(), which I did. SO, I got a little farther in the make process. Now I get the following error:

...
g++ -DHAVE_CONFIG_H -I. -I.. -DDATADIR='"/usr/local/share"' -DABS_TOP_SRCDIR='"/home/david/games/Hex/Benzene/fuego"' -pthread -I/usr/include -I../gtpengine -I../smartgame -I../go -I../gouct -O3 -g -Wall -Wextra -MT fuego-FuegoMain.o -MD -MP -MF .deps/fuego-FuegoMain.Tpo -c -o fuego-FuegoMain.o `test -f 'FuegoMain.cpp' || echo './'`FuegoMain.cpp
FuegoMain.cpp: In function ‘boost::filesystem3::path {anonymous}::GetProgramDir(const char*)’:
FuegoMain.cpp:63:55: error: invalid conversion from ‘bool (*)(const string&) {aka bool (*)(const std::basic_string&)}’ to ‘boost::enable_if_c::type* {aka void*}’ [-fpermissive]
In file included from /usr/include/boost/filesystem/path.hpp:31:0,
from FuegoMain.cpp:10:
/usr/include/boost/filesystem/v3/path.hpp:131:5: error: initializing argument 2 of ‘boost::filesystem3::path::path(const Source&, typename boost::enable_if::type> >::type*) [with Source = const char*; typename boost::enable_if::type> >::type = void]’ [-fpermissive]
make[2]: *** [fuego-FuegoMain.o] Error 1
make[2]: Leaving directory `/home/david/games/Hex/Benzene/fuego/fuegomain'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/david/games/Hex/Benzene/fuego'
make: *** [all] Error 2
david@achernar:~/games/Hex/Benzene/fuego$

I don't know enough about C++ to make a lucky guess in this case.
What do FuegoMain.cpp lines 61-65 look like?

would be very interesting to have a strong bot here. I just hope it doesnt increase the cheating in hex

Surely the availability of a strong bot is not going to decrease the level of cheating :-). But IMHO that would be a very cheap price to pay for it.

I apologize for hijacking this thread, but unfortunately, the developers of Benzene have not been active in their own help thread for many months. The only way Mohex will come to LG, it seems, is if someone finds a way to build it. So, the problems I encounter in building from source might pertain to someone else trying to do the same thing.

FWIW, here are lines 59-64 of FuegoMain.cpp:

bc.path GetProgramDir(const char* programPath)
{
if (programPath == 0)
return "";
return path(programPath, boost::filesystem::native).branch_path();
}

It would seem, I need to get rid of that reference to "native" somehow. I posted this question on the Fuego-devel mailing list, and got this reply from Martin Mueller:

"It seems the version of Fuego used for Hex is older than the version that adds support for the new boost filesystem. I think it makes more sense to talk to the Benzene developers and ask them to upgrade to a newer Fuego.

That said, I do believe that there is still a switch in boost to downgrade it to the old (Version 2) file system. Or maybe your best bet is to install an older boost version on your machine, which works with the old Fuego."

So, it looks like there are three possible paths for me:

1. Find some way to hack version 1163 of Fuego as well as Benzene.

2. Install an older set of Boost libraries on my machine.

3. Find (or build?) another GUI which will work with MoHex and Wolve, the two Hex engines that come with Benzene.

User ab mentioned his own version of HexGUI. I wonder...

I managed to compile mohex (latest revision) with the latest svn fuego. Didn't try to compile wolve and the tests, these may still fail. Boost version was 1.50.

Changed files:

src/util/Misc.cpp:
parent_path -> branch_path()
native_file_string() -> native()

src/mohex/MoHexEngine.cpp:
boost::TIME_UTC -> 1

Then I corrected the path to libfuego_gtpengine.a and libfuego_smartgame.a (benzene expects them in the fuego source directory, not in build). Libs can also be copied to the source dir.

Also needed to add -lpthread to linker flags.

Playing against mohex works fine with hexgui 0.9.

Is mohex latest revision the same as in the benzene 0.9.0 tarball? I do not find the lines you mention in Misc.cpp. Is there some URL I should use with an svn command?

Thanks for any clue.

I made a checkout of the benzene source repository at

git://benzene.git.sourceforge.net/gitroot/benzene/benzene

With the "->" i mean replace, e.g. in src/util/Misc.cpp, line 31:

- programDir = path(argv[0], native).branch_path();
+ programDir = path(argv[0]).parent_path();

Thanks, that's a big help, but I still get errors trying to build fuego. Here is a breakdown of everything I did, from the top:

I created a directory which I call my git directory. Within it I issued the command

@git clone git://benzene.git.sourceforge.net/gitroot/benzene/benzene@

This created a subdirectory benzene. I edited the following files in benzene:

bc.in src/util/Misc.cpp, line 31:
- programDir = path(argv0, native).branch_path();
+ programDir = path(argv0).parent_path();
line 73
- programDirFile = p.native_file_string();
+ programDirFile = p.native();
line 81
- absFile = p.native_file_string();
+ absFile = p.native();
line 89
- absFile = p.native_file_string();
+ absFile = p.native();
src/mohex/MoHexEngine.cpp line 476
- boost::xtime_get(&time, boost::TIME_UTC);
+ boost::xtime_get(&time, 1);

Then I returned to the git directory and issued these commands. The version of fuego was between 1600 and 1700. Everything worked fine until the error message:

bc.% svn co https://fuego.svn.sourceforge.net/svnroot/fuego/trunk fuego
% cd fuego
% autoreconf -i
% ./configure
% make
...
g++ -g -O2 -DNDEBUG -Wall -Wextra -L/usr/lib -o fuego fuego-FuegoMain.o fuego-FuegoMainEngine.o fuego-FuegoMainUtil.o ../gouct/libfuego_gouct.a ../go/libfuego_go.a ../smartgame/libfuego_smartgame.a ../gtpengine/libfuego_gtpengine.a -lboost_program_options-mt -lboost_filesystem-mt -lboost_system-mt -lboost_thread-mt
/usr/include/boost/thread/pthread/recursive_mutex.hpp:55: error: undefined reference to 'pthread_mutexattr_init'
/usr/include/boost/thread/pthread/recursive_mutex.hpp:60: error: undefined reference to 'pthread_mutexattr_settype'
/usr/include/boost/thread/pthread/recursive_mutex.hpp:73: error: undefined reference to 'pthread_mutexattr_destroy'
/usr/include/boost/thread/pthread/recursive_mutex.hpp:70: error: undefined reference to 'pthread_mutexattr_destroy'
/usr/include/boost/thread/pthread/recursive_mutex.hpp:63: error: undefined reference to 'pthread_mutexattr_destroy'
collect2: error: ld returned 1 exit status
make[2]: *** [fuego] Error 1
make[2]: Leaving directory `/home/david/games/Hex/software/Benzene/git/fuego/fuegomain'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/david/games/Hex/software/Benzene/git/fuego'
make: *** [all] Error 2
david@achernar:~/games/Hex/software/Benzene/git/fuego$

Any clue how to deal with this error would be most appreciated.

I didn't get to building MoHex yet. And I'm not clear how to do as you instruct. How would I add -lpthread to the linker flags? Should I manually edit the Makefile after I run config?

Also where is this build directory to which you refer? And where is the source directory into which I could copy those two library files? I find no src or source directory within the fuego directory.

I'm very grateful for your patience.

You don't actually need to build the fuego program, just libfuego_smartgame.a and libfuego_gtpengine.a is sufficient. Benzene expects the library files where you have them now, so you can go back building benzene. I set up a dedicated build directory for the fuego libs so I had to copy them.

The error you mention should be fixed by adding -lpthread to the linker flags. Since I don't know how to mess with autoconf files I just manually edited the Makefile (added -lpthread (you can also try the -pthread flag) to BOOST_THREAD_LIBS).

For me editing the Makefile did not work, but editing config.status did. I added the flags. and that error went away, thanks. Maybe I didn't have to build all of fuego, but I just want to write down the simplest procedure that should work for everyone. So, I completed building fuego, cd ../benzene, and ran autoreconf -i and ./configure --with-fuego-root=[absolute path to fuego] and then edited the config.status file for benzene the same as for fuego. Then when I ran make, I got a new error. Let's see if I can finally get that textile bc tag to work:

bc. ...
g++ -DHAVE_CONFIG_H -I. -I../../src -pthread -I/usr/include -DABS_TOP_SRCDIR='"/home/david/games/Hex/software/Benzene/git/benzene"' -DDATADIR='"/usr/local/share/benzene"' -I/home/david/games/Hex/software/Benzene/git/fuego/gtpengine -I/home/david/games/Hex/software/Benzene/git/fuego/smartgame -I../../src/ -O3 -g -DNDEBUG -Wall -pedantic -ansi -Wextra -Wconversion -MT libutil_a-Misc.o -MD -MP -MF .deps/libutil_a-Misc.Tpo -c -o libutil_a-Misc.o `test -f 'Misc.cpp' || echo './'`Misc.cpp
Misc.cpp: In function ‘void benzene::MiscUtil::FindProgramDir(int, char**)’:
Misc.cpp:31:23: error: ‘argv0’ was not declared in this scope
make[3]: *** [libutil_a-Misc.o] Error 1
make[3]: Leaving directory `/home/david/games/Hex/software/Benzene/git/benzene/src/util'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/david/games/Hex/software/Benzene/git/benzene/src'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/david/games/Hex/software/Benzene/git/benzene/src'
make: *** [all-recursive] Error 1
david@achernar:~/games/Hex/software/Benzene/git/benzene$

Make is complaining about line 31 in Misc.cpp, which was one of the lines I changed according to your instructions. Here are lines 27-32:

bc. void MiscUtil::FindProgramDir(int argc, char* argv[])
{
if (argc == 0 || argv == 0)
return;
programDir = path(argv0).parent_path();
}

Did I edit it incorrectly?

path(argv0) should be path(argv)

marvin_bot's second most recent previous post has a superscript 0 after each occurrence of argv. I can only presume the unmodified Misc.cpp has argv with no 0. Could the superscript 0 be an artifact introduced by Little Golem's textile?

@path(argv0)@ should be @path(argv\[0\])@

The 0 after argv should be in square brackets as it is an array index.

sry @path(argv[0])@

I agree.

Textile must have interpreted the bracketed 0 as a superscript. Should be path(argv[0])

You're right, thank you again, and that error is gone. We're getting there! Make goes a little farther and crashes here:

bc. Making all in book
make[3]: Entering directory `/home/david/games/Hex/software/Benzene/git/benzene/src/book'
g++ -DHAVE_CONFIG_H -I. -I../../src -pthread -I/usr/include
-DABS_TOP_SRCDIR='"/home/david/games/Hex/software/Benzene/git/benzene"'
-DDATADIR='"/usr/local/share/benzene"' -I/home/david/games/Hex/software/Benzene
/git/fuego/gtpengine -I/home/david/games/Hex/software/Benzene/git/fuego
/smartgame -I../../src/ -I../../src/hex -I../../src/util -O3 -g -DNDEBUG
-Wall -pedantic -ansi -Wextra -Wconversion -MT libbook_a-Book.o -MD -MP -MF
.deps/libbook_a-Book.Tpo -c -o libbook_a-Book.o `test -f 'Book.cpp' || echo
'./'`Book.cpp
In file included from Book.hpp:11:0,
from Book.cpp:9:
../../src/util/HashDB.hpp:14:16: fatal error: db.h: No such file or directory
compilation terminated.
make[3]: *** [libbook_a-Book.o] Error 1
make[3]: Leaving directory `/home/david/games/Hex/software/Benzene/git/benzene/src/book'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/david/games/Hex/software/Benzene/git/benzene/src'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/david/games/Hex/software/Benzene/git/benzene/src'
make: *** [all-recursive] Error 1
david@achernar:~/games/Hex/software/Benzene/git/benzene$

Here is the beginning of src/util/HashDB.hpp:

bc. //----------------------------------------------------------------------------
/\*\* @file HashDB.hpp */
//----------------------------------------------------------------------------
//
#ifndef HASHDB_H
#define HASHDB_H
//
#include
//
#include
#include
#include
//
#include

Maybe there is some hash table package I need to install?

db.h is from "The Berkeley DB embedded database system". The package should be called "db".

Thanks. My distro is Linux Mint Debian. I installed a mess of Berkeley DB packages,
probably more than I needed to.

bc. db5.1-sql-util
db5.1-util
libdb5.1-dbg
db5.1-doc
libdb5.1++-dev
libdb5.1-dev
libdb5.1-sql-dev
libdb5.1
libdb5.1++
libdb5.1-sql
libdb5.1-stl-dev
libdb5.1-stl

There are also tcl and java packages for db, but I left them out. Make now crashes in Wolve, which you have not built, but I was hoping to be able to build all of Benzene. Here is the error.

bc. g++ -O3 -g -DNDEBUG -Wall -pedantic -ansi -Wextra -Wconversion -L/usr/lib
-o wolve wolve-WolveEngine.o wolve-WolveMain.o wolve-WolvePlayer.o wolve-
WolveProgram.o wolve-WolveSearch.o wolve-WolveTimeControl.o
../commonengine/libcommonengine.a ../solver/libsolver.a ../book/libbook.a
../hex/libhex.a ../util/libutil.a
/home/david/games/Hex/software/Benzene/git/fuego/smartgame/libfuego_smartgame.a
/home/david/games/Hex/software/Benzene/git/fuego/gtpengine
/libfuego_gtpengine.a -lboost_filesystem-mt -lboost_program_options-mt
-lboost_system-mt -lboost_thread-mt -lpthread -pthread
../../src/util/HashDB.hpp:139: error: undefined reference to 'db_create'
../../src/util/HashDB.hpp:141: error: undefined reference to 'db_strerror'
../../src/util/HashDB.hpp:139: error: undefined reference to 'db_create'
../../src/util/HashDB.hpp:141: error: undefined reference to 'db_strerror'
collect2: error: ld returned 1 exit status
make[3]: *** [wolve] Error 1
make[3]: Leaving directory `/home/david/games/Hex/software/Benzene/git/benzene/src/wolve'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/david/games/Hex/software/Benzene/git/benzene/src'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/david/games/Hex/software/Benzene/git/benzene/src'
make: *** [all-recursive] Error 1
david@achernar:~/games/Hex/software/Benzene/git/benzene$

Here are lines 133-162 of src/util/HashDB.hpp:

bc. template
HashDB::HashDB(const std::string& filename, const std::string& type)
: m_db(0),
m_filename(filename)
{
int ret;
if ((ret = db_create(&m_db, NULL, 0)) != 0)
{
fprintf(stderr, "db_create: %s\n", db_strerror(ret));
throw BenzeneException("HashDB: opening/creating db!");
}
if ((ret = m_db->open(m_db, NULL, filename.c_str(), NULL,
DB_HASH, DB_CREATE, PERMISSION_FLAGS)) != 0)
{
m_db->err(m_db, ret, "%s", m_filename.c_str());
throw BenzeneException("HashDB: error opening db!");
}
Header newHeader(type);
Header oldHeader;
if (GetHeader(oldHeader))
{
if (newHeader != oldHeader)
throw BenzeneException()
<< "HashDB: Conflicting database types. "
<< "old: '" << oldHeader.m_type << "' "
<< "new: '" << newHeader.m_type << "'\n";
}
else
PutHeader(newHeader);
}

Maybe I didn't install enough?

Have you rerun configure after installing db? This is needed because configure looks for the db package and adds -ldb if it is found.

Of course your original configure run should have failed and complained about the missing db dependency...

Btw have you taken notice of these configure flags?

--enable-upto19x19 support boards up to 19x19 (default is no)
--enable-upto14x14 support boards up to 14x14 (default is no)
--enable-upto13x13 support boards up to 13x13 (default is no)

It works! Thanks for your immense help. I posted all the steps I took in the benzene help thread. For those who build their own, you might also be interested in this thread which discusses how to change the time control so that MoHex will be slower and stronger.

I wrote some mods to the Hexgui source code so the display would show alternate grids. I added border colors to replace the four off-board stones, and a display of triangles is now available, where the stones are on the intersections. Here are some screen shots including the original display which is still available.

!http://cf.geekdo-images.com/images/pic1508525.png!

!http://cf.geekdo-images.com/images/pic1508523.png!

!http://cf.geekdo-images.com/images/pic1508524.png!

!http://cf.geekdo-images.com/images/pic1508526.png!

Of course the display resizes with the window. I would like to post this new source tarball so that others can use it, but I'm not sure where or how.

Oh and yes, thank you, I saw the configure flags. The README file mentions them. I will probably build three versions of Mohex so it will be as strong as possible for a given grid size.

Are your mods for hexgui available somewhere? I'm particularly interested in the triangle grid style (fourth image) as this is how I made my wooden boards (I'm a Go player and I like my stones on grid intersections ^^). Is this style also available in flat orientation?

Yes.

!http://cf.geekdo-images.com/images/pic1508678.png!

My email is twixtfanatic atsymbol gmail period com.
I could email the tarball to whoever wants it.
If anyone knows of a site I can upload it to for free, please let me know.