[Computer-go] pachi: how to build?

Petr Baudis pasky at ucw.cz
Fri Apr 15 06:37:48 PDT 2011


On Fri, Apr 15, 2011 at 02:12:48PM +0100, Jonathan Chetwynd wrote:
> I would like to try pachi, that is why I am trying to build,
> most developers including myself are extremely keen to get feedback,
> I encourage you to start a pachi forum already, it is essential that
> developers and users can find answers quickly and easily

  So far, we've been getting very little feedback so it didn't seem
worthwhile to create an infrastructure for this. Perhaps a mailing list
would indeed be useful. We'll think of something.

> I have compiled hundreds, but probably not thousands of
> applications, on linux and mac,
> without ever using more than config, make and install...
> I have rarely  needed to read or edit a makefile
> there is no documentation afaict,

  There's an "Installation" section in the README, but right now it
covers just Linux since we do not use other OSes on regular basis. Let's
figure out what's needed to get and keep Pachi going on Mac now and
document that in the README.

> and I received no response,
> although I made my interest plain.

  Please do not take offense. We simply aren't able to guarantee
response time under 24 hours. :-)

> Jay:pachi 2 jonathanchetwynd$  make MAC=1
> [LINK] zzgo
> Undefined symbols:
>   "___sync_fetch_and_add", referenced from:
>   "___sync_synchronize", referenced from:
>   "___sync_fetch_and_sub", referenced from:
>   "___sync_lock_test_and_set", referenced from:
> ld: symbol(s) not found
> collect2: ld returned 1 exit status
> make: *** [zzgo] Error 1

  These intrinsics are provided by gcc 4.1 and newer, but your cc does
not appear to provide them. Just out of interest, is that gcc and what
is it's version? (cc --version)

  There are few ways from here...

  (i) Disable multi-threading support on MAC. Are you actually
interested in running Pachi with multiple threads in your use-case?

  (ii) Use non-synchronized operations instead. It opens few race
conditions, but they should not be fatal and it is not clear if they
would impair program strength significantly, especially with shorter
thinking times.

  (iii) Substitute with proper OS/X calls, e.g. as described in:


The complication is that I wouldn't be able to properly test this on
my own.

				Petr "Pasky" Baudis
UNIX is user friendly, it's just picky about who its friends are.

More information about the Computer-go mailing list