Subject: Re: no pthread_spinlock_t on Mac OS 10.6.4

From: "Gary V. Vaughan" <[email-masked]>
Date: Wed, 22 Sep 2010 15:18:29 +0700

Hi Paul,

On 22 Sep 2010, at 02:03, Paul Eggert wrote:
> Gary, could you please also try the following patch to coreutils,
> either by itself,

gcc -std=gnu99  -I. -I../../src -I../lib  -I../../lib    -g -O2 -MT sort.o -MD -MP -MF .deps/sort.Tpo -c -o sort.o ../../src/sort.c
../../src/sort.c:243: error: expected specifier-qualifier-list before 'pthread_spinlock_t'
../../src/sort.c: In function 'lock_node':
../../src/sort.c:3159: warning: implicit declaration of function 'pthread_spin_lock'
../../src/sort.c:3159: error: 'struct merge_node' has no member named 'lock'
../../src/sort.c: In function 'unlock_node':
../../src/sort.c:3167: warning: implicit declaration of function 'pthread_spin_unlock'
../../src/sort.c:3167: error: 'struct merge_node' has no member named 'lock'
../../src/sort.c: In function 'sortlines':
../../src/sort.c:3445: error: 'pthread_spinlock_t' undeclared (first use in this function)
../../src/sort.c:3445: error: (Each undeclared identifier is reported only once
../../src/sort.c:3445: error: for each function it appears in.)
../../src/sort.c:3445: error: expected ';' before 'lock'
../../src/sort.c:3446: warning: implicit declaration of function 'pthread_spin_init'
../../src/sort.c:3446: error: 'lock' undeclared (first use in this function)
../../src/sort.c:3448: warning: excess elements in struct initializer
../../src/sort.c:3448: warning: (near initialization for 'node')
../../src/sort.c: In function 'sort':
../../src/sort.c:3759: error: 'pthread_spinlock_t' undeclared (first use in this function)
../../src/sort.c:3759: error: expected ';' before 'lock'
../../src/sort.c:3760: error: 'lock' undeclared (first use in this function)
../../src/sort.c:3763: warning: excess elements in struct initializer
../../src/sort.c:3763: warning: (near initialization for 'node')

> or along with the updated gnulib patch?

Builds, and sort appears to be working, as it was in my last message on this thread.

Actually this patch seems to make no discernable difference to the behaviour of the build in both cases above.

> configure: default gnulib to not using threads
> 
> * configure.ac: Set gl_use_threads_default=no so that gnulib is
> configured without threading.  The only coreutils application that
> uses threads (namely 'sort') does not invoke gnulib code in ways
> that could lead to races.  Setting this flag simplifies
> configuration, making it less likely for builds to fail, and
> perhaps preventing some runtime gotchas.

Cheers,
-- 
Gary V. Vaughan ([email-masked])