MySQL Bugs: #28456: my_global.h inappropriately depends on kernel header asm/atomic.h

Bug #28456	my_global.h inappropriately depends on kernel header asm/atomic.h
Submitted:	16 May 2007 0:45	Modified:	29 Jun 2007 18:37
Reporter:	Monty Taylor
Status:	Verified
Category:	Server: Compiling	Severity:	S3 (Non-critical)
Version:	5.0.38	OS:	Linux
Assigned to:		Target Version:
Triage:	Triaged: D3 (Medium)

Description:
Got the following reported downstream in debian (debian bug#424276)

Packages build-depending on libmysqlclient15-dev will fail to build in
unstable on (at least) amd64 systems using the new linux-libc-dev package in
place of the obsoleted linux-kernel-headers, because my_global.h has a
dependency on asm/atomic.h:

 gcc -DHAVE_CONFIG_H -I. -I. -I. -D_REENTRANT -D_GNU_SOURCE -I/usr/include -O3 -DDBUG_OFF
-I/usr/include/mysql -DBIG_JOINS=1 -g -Wall -O2 -MT libmyodbc3_la-catalog.lo -MD -MP -MF
.deps/libmyodbc3_la-catalog.Tpo -c catalog.c  -fPIC -DPIC -o
.libs/libmyodbc3_la-catalog.o
In file included from ../MYODBC_MYSQL.h:11,
                 from myodbc3.h:37,
                 from catalog.c:44:
/usr/include/mysql/my_global.h:353:24: error: asm/atomic.h: No such file or directory
make[3]: *** [libmyodbc3_la-catalog.lo] Error 1

According to kernel upstream[1], asm/atomic.h is not an appropriate header
for inclusion from userspace; and indeed, on some architectures such as
i386, libmysqlclient works fine without HAVE_ATOMIC_ADD being defined.

I suspect that a simple rebuild (i.e., binNMU) of mysql-dfsg-5.0 against
linux-libc-dev would be enough to fix the symptoms of this bug, but I'm
filing a sourceful bug report instead for two reasons:

- not all buildds have linux-libc-dev installed yet, and this won't be
  enforced for some time, making it difficult to get this issue covered for
  all archs in a timely manner through binNMUs
- even if asm/atomic.h is present on the system, it is still an error for
  libmysqlclient15-dev to depend on it, and this is a bug in the source
  package which should be fixed by hard-disabling the check.

Please fix this bug ASAP so that developing against libmysqlclient on
amd64/unstable works again.

How to repeat:
I'm guessing that trying to build something on a recent Debian sid system that has
replaced the linux-kernel-headers package with the linux-libc-dev package would be a good
start.

Suggested fix:
Don't use asm/atomic.h if it's not intended to be public. Or put something in configure
that prevents its use on platforms that don't have it better.

Thank you for the report.

Verified as described using code analysis.

See also http://docs.fedoraproject.org/release-notes/fc6/en_US/sn-Devel.html:

12.2.1. Kernel header files
<skip>
    * The <asm/atomic.h> and <asm/bitops.h> header files have been removed. These were
not designed for use in userspace, and would fail to compile on some architectures while
silently giving non-atomic behaviour on others. The C compiler provides its own atomic
builtin functions that are suitable for use in userspace programs instead.

Related to Bug#21554

I downloaded mysql-5.0.45-linux-x86_64-glibc23.tar.gz and encountered the error mentioned
by the reporter, while trying to build a UDF with the following command:

gcc -fPIC -Wall -I/home/baron/5.0.45/include/ -shared -o now_usec.so now_usec.cc

Since the bug report seems to indicate atomic add might not be all that important, I
tried just removing the #include <asm/atomic.h> line, and the UDF built okay.  But now,

master [localhost] {msandbox} (mysql) > create function now_usec returns string soname
'now_usec.so';
ERROR 1126 (HY000): Can't open shared library 'now_usec.so' (errno: 22 /lib/now_usec.so:
undefined symbol: __gxx_personality_v0)

I'm adding this comment in hopes it's related.  Ubuntu 7.04 on AMD64:

baron@tigger rsandbox $ uname -a
Linux tigger 2.6.20-16-generic #2 SMP Sun Sep 23 18:31:23 UTC 2007 x86_64 GNU/Linux

I confirm that this compile bug still exists in 5.0.46. The patch from #21554 applies with
a little bit of manual fixup.

Downstream Gentoo bug is https://bugs.gentoo.org/show_bug.cgi?id=197004

See this too -- http://lists.mysql.com/packagers/264

Note that the RHEL/CentOS source RPMs patch configure so that HAVE_ATOMIC_ADD is always
not defined and then the thread_safe_* functions use a mutex, so RHEL/CentOS users lose a
bit of performance.

#ifdef HAVE_ATOMIC_ADD
#define thread_safe_increment(V,L) atomic_inc((atomic_t*) &V)
#define thread_safe_decrement(V,L) atomic_dec((atomic_t*) &V)
#define thread_safe_add(V,C,L)     atomic_add((C),(atomic_t*) &V)
#define thread_safe_sub(V,C,L)     atomic_sub((C),(atomic_t*) &V)
#else
#define thread_safe_increment(V,L) \
        (pthread_mutex_lock((L)), (V)++, pthread_mutex_unlock((L)))
#define thread_safe_decrement(V,L) \
        (pthread_mutex_lock((L)), (V)--, pthread_mutex_unlock((L)))
#define thread_safe_add(V,C,L) (pthread_mutex_lock((L)), (V)+=(C),
pthread_mutex_unlock((L)))
#define thread_safe_sub(V,C,L) \
        (pthread_mutex_lock((L)), (V)-=(C), pthread_mutex_unlock((L)))
#endif /* HAVE_ATOMIC_ADD */