Bugzilla Bug 168931

If you re-emerge dev-db/mysql-5.0.32, the /usr/include/mysql/my_config.h file
does not get replaced with the new one generated by configure. This can cause
issues (for example) if mysql had previously been configured/built against an
older version of the sys-kernel/linux-headers (<=2.6.17-r2) which installs
/usr/include/asm/atomic.h, which the mysql build checks for, and #defines
HAVE_ATOMIC_{ADD,SUB} 1 in my_config.h, which in turn enables a #include of
<asm/atomic.h> in /usr/include/mysql/my_global.h. Then, if linux-headers is
upgraded to > 2.6.17-r2, any compilation which includes
/usr/include/mysql/my_global.h will fail (for example, see bug #168660), as it
can't find /usr/include/asm/atomic.h. I have verified that the MySQL configure
does generate a correct my_config.h with linux-headers > 2.6.17-r2 installed
(does not #define HAVE_ATOMIC_{ADD,SUB}), but /usr/include/mysql/my_config.h
does not get replaced with the newly generated one.

As a test, I moved the old /usr/include/mysql/my_config.h file to a temporary
location, then re-emerged dev-db/mysql-5.0.32 again, and this time it did
install the newly generated my_config.h file into /usr/include/mysql. However,
at the same time, I observed the following error towards the end of the build,
either immediately before or during the install phase:

install: cannot stat `/usr/include/mysql/my_config.h': No such file or
directory

Which leads me to believe that at some point, the MySQL build copies the
existing /usr/include/mysql/my_config.h to the build directory, overwriting the
newly generated one.

Reproducible: Always

Steps to Reproduce:
1. emerge -C dev-db/mysql (or just rm /usr/include/mysql/my_config.h)
2. emerge <=sys-kernel/linux-headers-2.6.17-r2
3. emerge =dev-db/mysql-5.0.32
4. grep HAVE_ATOMIC_ADD /usr/include/mysql/my_config.h
5. emerge >sys-kernel/linux-headers-2.6.17-r2
6. emerge =dev-db/mysql-5.0.32
--OR--
6.a ebuild /usr/portage/dev-db/mysql/mysql-5.0.32.ebuild compile
6.b grep HAVE_ATOMIC_ADD
/var/tmp/portage/dev-db/mysql-5.0.32/work/mysql/include/my_config.h
6.c ebuild /usr/portage/dev-db/mysql/mysql-5.0.32.ebuild qmerge
7. grep HAVE_ATOMIC_ADD /usr/include/mysql/my_config.h

Created an attachment (id=111751) [details]
mysql-5.0.32-no-atomic-ops.patch

I can confirm this. When I was troubleshooting bug #168660, I was a bit
mystified that I couldn't get it to error on me, even when I had an
asm/atomic.h in linux-headers and then upgraded and built sci-physics/root.
Since my very first build of mysql was on linux-headers-2.6.20-r1, it would of
course never have configured atomic writes, and since it inherits its config,
it wouldn't matter that I rebuilt it with 2.6.17-r2 headers. Attached to this
post is a patch that will make sure mysql is never built with atomic writes. It
is meant to be applied last, since I patched against what was in the build
directory. Since this patch has been used on Redhat mysql since the
4-series[1], I think it can be defined as being production ready. Getting mysql
to actually RE-configure every time it is RE-built should be as easy as
deleting my_config.h.

[1] from mysql-4.1.20-1.FC4.1.src.rpm:
The idea of userland using <asm/atomic.h> has our kernel hackers all bent
out of shape, so don't do it.  Suppressing this has another benefit too,
which is we avoid the 4-vs-8-byte problem in BDB that formerly required
mysql-threads.patch.


diff -Naur mysql-4.1.19.orig/configure.in mysql-4.1.19/configure.in
--- mysql-4.1.19.orig/configure.in      2006-04-29 01:35:51.000000000 -0400
+++ mysql-4.1.19/configure.in   2006-05-04 21:51:56.000000000 -0400

Copy/paste from bug #168660:
This list message suggests that it may be limited to 64 bit platforms only:
http://lists.mysql.com/packagers/264
Either way, lkml says including atomic.h is a /bad/ idea:
http://lkml.org/lkml/2006/7/10/417

*** Bug 168660 has been marked as a duplicate of this bug. ***

This bug also blocks bug 163151.

*** Bug 172570 has been marked as a duplicate of this bug. ***

This appears fixed in 5.0.40, appearing in the tree shortly.

*** Bug 184268 has been marked as a duplicate of this bug. ***