Re: This platform lacks a functioning sem_open implementation

2013-07-01 Thread Jeff Epler
On Thu, May 02, 2013 at 04:26:23PM +0200, Petr Salinger wrote: > Not really. We do not support "named semaphores" (sem_open), > but we do support (unnamed semaphores) (sem_init). > The "named only" functions returns ENOSYS. In Wheezy on kfreebsd? The implementation of sem_open in eglibc-2.13/linu

Re: This platform lacks a functioning sem_open implementation

2013-05-02 Thread Petr Salinger
At first glance it looks like some feature is not being detected/enabled during the python2.7 build. From https://buildd.debian.org/status/fetch.php?pkg=python2.7&arch=kfreebsd-amd64&ver=2.7.4-2&stamp=1365768399 : checking for sem_open... yes checking for sem_timedwait... yes checking for sem_ge

Re: This platform lacks a functioning sem_open implementation

2013-05-02 Thread Jérémy Lal
On 02/05/2013 15:00, Steven Chamberlain wrote: > Hi, > > On 02/05/13 08:55, Jérémy Lal wrote: >> ImportError: This platform lacks a functioning >> sem_open implementation, therefore, the required >> synchronization primitives needed will not function, >>

Re: This platform lacks a functioning sem_open implementation

2013-05-02 Thread Steven Chamberlain
Hi, On 02/05/13 08:55, Jérémy Lal wrote: > ImportError: This platform lacks a functioning > sem_open implementation, therefore, the required > synchronization primitives needed will not function, > see issue 3770. [...] > https://buildd.debian.org/status/fetch.php?pkg=libv8-3.1

This platform lacks a functioning sem_open implementation

2013-05-02 Thread Jérémy Lal
Hi, i'm looking at libv8-3.14 experimental build logs at [0], and i wonder if there is a known workaround for this exception : ImportError: This platform lacks a functioning sem_open implementation, therefore, the required synchronization primitives needed will not function, see issue