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 attachment 111751 [details, diff] 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. ***
