Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 111073

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] ServerAssignee: 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)

Description Gentoo Bug Tracking 2005-10-31 17:54:22 UTC
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
Comment 1 Gustavo Zacarias (RETIRED) gentoo-dev 2005-11-01 04:46:29 UTC
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).
Comment 2 Kerin Millar 2006-02-28 23:35:12 UTC
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.
Comment 3 Kerin Millar 2006-02-28 23:40:11 UTC
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.
Comment 4 Kerin Millar 2006-02-28 23:46:22 UTC
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.
Comment 5 Francesco R. (RETIRED) gentoo-dev 2006-03-01 01:35:12 UTC
Testing the patch right now
Comment 6 Herbie Hopkins (RETIRED) gentoo-dev 2006-03-01 01:58:13 UTC
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.
Comment 7 Kerin Millar 2006-03-01 17:44:21 UTC
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 :)
Comment 8 Kerin Millar 2006-03-01 17:46:24 UTC
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.
Comment 9 Francesco R. (RETIRED) gentoo-dev 2006-03-03 01:40:50 UTC
Fixed in the eclass at the moment.
Comment 10 Francesco R. (RETIRED) gentoo-dev 2006-03-18 03:35:24 UTC
fixed now, thanks everyone 
Comment 11 Francesco R. (RETIRED) gentoo-dev 2006-03-24 08:05:28 UTC
The bug was still _not_ fixed in 4.1.14 (stable), _many_ thanks to "Johan Lindh" for pointing this out.