| Summary: | mysql configure fails to locate zlib on multilib 64-bit systems (inc. amd64/sparc) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Gentoo Bug Tracking <gentoo-bugs> |
| Component: | [OLD] Server | Assignee: | Gentoo Linux MySQL bugs team <mysql-bugs> |
| Status: | VERIFIED FIXED | ||
| Severity: | major | CC: | amd64, hardened, kfm, ragnaroc |
| Priority: | High | Keywords: | Bug |
| Version: | unspecified | ||
| Hardware: | Sparc | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
mysql.eclass patch
Alternative patch Complementary "alternative patch" (for non-slotted ebuilds) |
||
We currently don't support pure 64-bit userland and/or multilib on sparc. I'm closing as LATER since multilib is in our plans at some point, when we get the proper resources (developers! developers! and time). I'm re-opening this because this doesn't just affect sparc. I've just run into this exact same problem on an amd64 system which has just been freshly setup using the "stage3-amd64-hardened+multilib-2006.0.tar.bz2" stage tarball. As I understand it, multilib on amd64 systems is supported! The work-around suggested by the original poster is not wise and should be avoided - it will probably result in the bundled zlib being used (bad). Anyhow, here's what I discovered: * All mysql ebuilds that do *not* use the new mysql/mysql_fx eclasses appear to be affected (i.e. ones without the -r30 revision suffix). * This includes mysql-4.1.14 which is the version currently marked stable. * The mysql eclass contains a working fix for mysql-5.x.x by replacing "$zlib_dir/lib" with "$zlib_dir/$(get_libdir)" in zlib.m4 (where get_libdir is a function provided by the multilib eclass and will return "lib64" as expected in this case). However, it does *not* correctly fix up prior versions. I'm attaching a patch for mysql.eclass which resolves the problem for versions prior to 5.x.x. With this I was able to unmask and install mysql-4.1.18-r30 without a hitch. Unfortunately, no matter how hard I tried, I was not able to make this work by directly putting the sed call in the src_unpack function of those ebuilds which *don't* use the eclass (including 4.1.14). I checked the macros in the mysql sources across the various versions and not a lot appears to have changed so I can only assume that the eclass does something else which alters the behaviour so that MYSQL_CHECK_ZLIB_DIR function in acinclude.m4/zlib.m4 is successful. So, the way I see it there are two choices: 1) Patch all ebuilds that don't use the eclass, most notably 4.0.14 which is marked stable, so that they correctly apply the fix (I haven't figured out how). Also, apply the patch I've provided so that the -r30 ebuilds work properly too. 2) Apply the patch I've provided and just get rid of the versions that don't use mysql.eclass and stabilise a version that *does* use such as 4.1.16-r30 or 4.1.18-r30. As this is a very annoying bug in my view and because the use of an eclass makes a lot of sense I'm in favour of option (2) for whatever it's worth. Created attachment 81013 [details, diff]
mysql.eclass patch
A modification to mysql.eclass which forces the zlib detection macros to use the correct libdir not just for mysql-5.x.x but for older versions too.
Cc'ing the hardened herd due to the stageball that was used (for informational purposes and because the bug didn't previously occur on this system using the standard 2005.1 amd64 profile). If it's of no interest then I apologise for the noise in advance. Testing the patch right now Created attachment 81017 [details, diff]
Alternative patch
Whilst the above patch looks like it'll work note that the problem here seems to be with the "--with-zlib-dir=/usr" option that is passed to configure which implies that zlib is installed in /usr/lib. If this option is not passed then the standard locations are all checked and zlib is detected well on amd64 at least. Unless you can think of a good reason that this option needs to be passed I think this is probably a neater fix.
Sorry guys - you're quite right. Herbie, that patch looks great. Here's one more patch which fixes up: * mysql-4.1.14.ebuild * mysql-4.1.16.ebuild * mysql-5.0.18.ebuild If this is committed to the tree along with your patch then I reckon that this bug should be history :) Created attachment 81083 [details, diff]
Complementary "alternative patch" (for non-slotted ebuilds)
Takes the same approach as patch 81017 but instead fixes up the non-slotted ebuilds.
Fixed in the eclass at the moment. fixed now, thanks everyone The bug was still _not_ fixed in 4.1.14 (stable), _many_ thanks to "Johan Lindh" for pointing this out. |
The configure script for mysql-4.1.14 is unable to find zlib "in /usr/{include,lib} when the following paramter is passed to econf in the ebuild: --with-zlib-dir=/usr If you remove that paramter the configure script automagically finds the zlib on the system and correclty builds. Again, this is on sparc 64-bit, where the libraries are in /usr/lib64 Reproducible: Always Steps to Reproduce: 1. emerge =dev-db/mysql-4.1.14 2. watch autoconf take forever and finally get going 3. see it fail trying to find zlib 4. shower, rinse, sleep, and repeat