How to eliminate "suspect libGlib-2.0" problem, if there is one?

Hey folks!

I was wondering, since I compile glib2.x myself for improving system performance, which is this wonderful flag that I have to use in order for Ardour to stop complaining about ‘mutex locking atomic operations’?

I searched the Forum and the internet but found nothing of relevance.


— TVP/ZM is what open source is all about, yay! —

@muadib: You have mis-compiled glib in a way that makes it not use real processor-based atomic based operations. The “fallback” totally changes the semantics of glib’s atomic operations. Fedora did this at one point - we reported it and they fixed the problem in an update.

Hey Paul! :slight_smile:

hmm…So is there a suggested way to recompile my glib-2.20? Or should I reinstall a specific version from the Fedora RPM repository?

— TVP/ZM is what open source is all about, yay! —

@muadib: no idea. a normal build of glib on almost any platform should pick up the processor-specific atomic instructions. if it doesn’t, it implies there is something else wrong with your system, preventing glib’s build process from deciding what type of platform it is.

Hmmm…If it helps, this is the output of ‘./configure --prefix=/usr’ at

on line 425 there is this: ‘# checking whether to use assembler code for atomic operations… i486’

Other than this I cannot see anything else… :frowning:

@muadib: i suggest you take it up on a glib mailing list or something similar. but first, run this command

nm -D --radix=dec --defined-only /usr/lib/ | grep -w g_atomic_int_add

and paste the output here

Thanks Paul, I will!

This command outputs:

“00072976 T g_atomic_int_add”

Any clues?