Il 30/05/2013 02:59, Paul Eggert ha scritto:
> On 05/26/2013 03:11 PM, Paolo Bonzini wrote:
>> Use the lock module instead.
>
> Adding the lock module should work. But this will require
> some reengineering of Guile, so that Guile uses the lock module
> rather than its own thread packaging. Anot
On 05/26/2013 03:11 PM, Paolo Bonzini wrote:
> Use the lock module instead.
Adding the lock module should work. But this will require
some reengineering of Guile, so that Guile uses the lock module
rather than its own thread packaging. Another possibility, which
might be a bit simpler, would be
Il 20/05/2013 16:20, Ludovic Courtès ha scritto:
> Paul Eggert skribis:
>
>> On 05/14/2013 02:21 PM, Ludovic Courtès wrote:
>>
>>> How should that be fixed? Shouldn’t __libc_lock_unlock & co. be rebased
>>> on top of pthread_mutex_t?
>>
>> Yes, thanks, that sounds right. I pushed the following
Paul Eggert skribis:
> On 05/14/2013 02:21 PM, Ludovic Courtès wrote:
>
>> How should that be fixed? Shouldn’t __libc_lock_unlock & co. be rebased
>> on top of pthread_mutex_t?
>
> Yes, thanks, that sounds right. I pushed the following patch into gnulib;
> could you please see whether it fixes
On 05/14/2013 02:21 PM, Ludovic Courtès wrote:
> How should that be fixed? Shouldn’t __libc_lock_unlock & co. be rebased
> on top of pthread_mutex_t?
Yes, thanks, that sounds right. I pushed the following patch into gnulib;
could you please see whether it fixes the problem for you? It'd be
hel
Hello,
Guile imports Gnulib ‘regexp’ module, and for some reason it gets
compiled even on glibc systems.
The problem is that Gnulib’s ‘regex_internal.h’ reads this:
#if defined _LIBC
# include
#else
# define __libc_lock_init(NAME) do { } while (0)
# define __libc_lock_lock(NAME) do {
