glibc glib-2.25.16 error: 'g__cancellable_lock' undeclared
 

compiling glibc MANY have gotten stopped build with this compile error:

error: 'g__cancellable_lock' undeclared

NOTE: THERE ARE MANY BOGUS FORUMS POSTING WRONG CAUSE AND WRONG SOLUTION. specifically: it does not mean you should disable threads as stackexchange.com says.

check config.log if you see this then you did options wrong

checking for thread implementation... no

I have build GNU/Linux (circa 2010 source codes) from termcap to X11R7.6, and all required inbtween). Tens of pkgs needed given the verions i chose to build as the "toolchain": glib had two (threads err, and msgctxt err).

glib's configure script uses --?thread option in an non-standard way comparable to others and does NOT detect pthreads automatically (which most others do).

read "./configure --help" carefully and litterally, do not use --enable-threads=yes, nor --enable-pthreads: use only --with-threads=posix

# you'll now see configure prints this:

checking for thread implementation... posix
checking thread related cflags... -pthread
checking for sched_get_priority_min... yes
checking thread related libraries... -pthread


other wrong advice i found is to rewrite gcancellable.c so that attempts to lock are simply skipped (assume thread support IS OFF i hope). wrong because for gnu/linux (esp debian) you have threads you simply didn't use your options right :)

>> +#ifdef G_THREADS_ENABLED
>> + G_LOCK(cancellable);
>> +#endif
>> +/*only for cancellable*/

THREAD BACKGROUND:

unix has had posix threads for many years (many decades perhaps)

many first get an error message while compiling glibc (std C lib) "...atomic...lock is undefined" if they goof the configure option for compiling gcc4. on non-gnu or none linux your mileage may vary?

if your using GNU/Linux "i386-pc-linux-gnu" then when gcc-4.4.5 was made it SHOULD HAVE been given options to enable posix threads (which isn't default you have to give options to configure)

all it does is gives gcc a "built-in" for using the CPU's "LOCK" command (the assembler instruction: LOCK. very minute ability and very troublesome if it is not added). an ASM (.S) program or linux call could activate the LOCK instruction (infact there are ?15 atomic libs? not very atomic then?) but that's irrelevant since when programs compile /usr/include/pthreads.h needs to "just work". <pthreads.h> works in gnu/linux by it being built-in to gcc, gcc installs ptheads.h

(obvioulsy on non-gnu systems <pthreads.h> will #define things so that the applications get their LOCK command even if it is not in the non-gnu compiler)