link fails for GCC atomic functions

[GoogleCodeExporter]

What steps will reproduce the problem?
1. configure && make

What is the expected output? What do you see instead?
Error:
gcc -std=gnu99  -g -O2 -pthread -pthread -Wall -Werror -pedantic 
-Wmissing-prototypes -Wmissing-declarations -Wredundant-decls   -o memcached 
memcached-memcached.o memcached-hash.o memcached-slabs.o memcached-items.o 
memcached-assoc.o memcached-thread.o memcached-daemon.o memcached-stats.o 
memcached-util.o memcached-cache.o    -levent -lrt 
memcached-thread.o: In function `refcount_decr':
/root/adam/cache/memcached-1.4.15/thread.c:102: undefined reference to 
`__sync_sub_and_fetch_2'
memcached-thread.o: In function `refcount_incr':
/root/adam/cache/memcached-1.4.15/thread.c:87: undefined reference to 
`__sync_add_and_fetch_2'

What version of the product are you using? On what operating system?
memcached 1.4.15 or 1.4.14
libc 2.8
gcc 4.3.3
Linux 2.6.39.3

Please provide any additional information below.
This was resolved by adding -march=i686 to CFLAGS when running "configure".

Original issue reported on code.google.com by mirkp...@gmail.com on 17 Dec 2012 at 8:58

[GoogleCodeExporter]

what OS/distro is this? 32bit or 64bit?

was pretty sure I'd gotten the configure tests to actually *test* the atomic 
call and fall back to the mutex if it breaks. It works under all of the OS's I 
test under at least. what's yours, exactly?

Original comment by dorma...@rydia.net on 18 Dec 2012 at 1:14

[GoogleCodeExporter]

The Linux distro I'm using is Crux 2.5, very unknown and at this point 2.5 is 
well out of date.  We largely use it as a base and then roll our own software 
upgrades on top of it, but we haven't updated libc or gcc.  We're using 32-bit 
on Intel Xeon processors.

Since the atomic calls work with -march=i686, should the configure script 
figure out if it should be using that or whatever appropriate march type 
anyways?

Are the atomic calls significantly better than the mutex?

Original comment by mirkp...@gmail.com on 18 Dec 2012 at 8:51

[GoogleCodeExporter]

Take a look through the configure script, it's supposed to actually test and 
use the atomic call, and fail back if it fails.

The problem is that 32bit x86 doesn't have 16bit atomics, so they have to be 
detected and disabled. Except some versions of GCC (the one you have) claims to 
have them anyway, and it'll fail at runtime. 32bit is stuck with the mutex, but 
given how much memory you're limited to, I doubt you'd ever notice the 
performance drop. It just won't be hugely faster than .11.

I have no idea why setting march=i686 makes it work right, and I don't have 
your OS to test on :/ Since that's all pretty old legacy stuff, we might have 
to insist you compile with your workaround.

I'd consider a patch to the autocrap if it doesn't degrade any of our supported 
platforms.

Original comment by dorma...@rydia.net on 18 Dec 2012 at 9:01

[GoogleCodeExporter]

I'm happy to continue using the workaround of setting -march=i686, I just 
wanted to log this in case it was a bigger problem.  I poked around the 
configure code before logging this ticket but didn't work on it long enough to 
figure out why the test was passing.

Although maybe it would be nice to have mention of this in the README or 
somewhere in regards to building memcached?  I had to hunt around google for a 
while to figure out how to get the build to work, and if it is safe to use 
-march=i686 on 64bit x86 with 32bit Linux to get the atomics, then maybe a "If 
you get this error on 64bit x86, try -march=i686" note?

Original comment by mirkp...@gmail.com on 18 Dec 2012 at 9:11

[GoogleCodeExporter]

maybe? It's going to be a pretty rare issue, and you filing this bug actually 
helps the google-ability of the problem quite a lot. I was also pretty sure it 
was fixed last time it was reported, and has stayed fixed on 32bit centos 
instances with the affected GCC versions.

Also this is the first time it's been reported as fixable by setting march=i686 
:P That didn't work when I'd originally fixed the bug.

So it's all novel, at this point. I'll leave this open until someone reviews if 
there's a good place to leave a note (or if it's fixable).

Original comment by dorma...@rydia.net on 18 Dec 2012 at 9:25