Hm, so I looked into this a bit further, and it seems not so easy to fix... The problem is that -all-static is really a libtool special option, but configure checks do not use libtool. So configure cannot easily in a generic may make libtool options set by the user affect its decision. In fact, I think passing -all-static to libtool via --with-mysqld-ldflags in the way the MySQL source does is heavy abuse of libtool (also according to automake/libtool docs). But that is another matter... My conclusion is that this should not be fixed in ./configure. If someone decides to pass in -all-static, they should have the responsibility to add any extra options needed to make linking -all-static actually work. In this case --with-zlib-dir=bundled. (Another issue is that your CentOS/Fedora should maybe provide both libz.so and libz.a, don't understand why it does not? But that is another discussion). So the fix I suggest is to simply add --with-zlib-dir=bundled in BUILD/compile-pentium64-max (I already committed this change for review). Or even better, avoid using -all-static, which really creates more problems than it solves (but that also is another discussion). Thanks again, - Kristian. Kristian Nielsen <knielsen@knielsen-hq.org> writes:
Don Kehn <dekehn@gmail.com> writes:
This is how I got it to work and there maybe an issue here: using the BUILD/compile-pentium64-max, changed the changed the extra_configs="$pentium_configs $max_configs $static_link" to extra_configs="$pentium_configs $max_configs" (notice the static_link is removed). It is trying to link with --all-static (thus it needs zlib.a libssl.a .....), which is a pain in the ars, I'm wondering if this is an issue for the build team. I believe this is the only *max that has the static_link. libtool ... uses --all-static which leads to the gcc -static ....-lz -lpthread, anything on the commandline after the -static MUST be statically linked thus is not found in my case. Have confirmed this on two different fedora core 10 - 64-bit systems.
Ah, thanks for digging up this, I think I understand now.
Probably on your system, you have libz.so but no libz.a.
The $static_link expands to
--with-mysqld-ldflags=-all-static --with-client-ldflags=-all-static
These are extra linker flags added when linking specific executables. So they are _not_ added generally to $LDFLAGS in configure.in (and anyway the checks for --with-mysqld-ldflags and --with-client-ldflags are after the check for libz in configure.in). So these flags are not used when checking for libz, and hence ./configure decides it can use the system libz. But when it then gets to actually link mysqld, it fails due to missing static library for libz.
So the BUILD/compile-pentium64-max script is probably not used much. For development people generally will use BUILD/compile-pentium64-debug-max instead, and the release builds are not made with the scripts in BUILD/. That is probably the reason this has not been fixed yet.
So the work-around for you could be to just use BUILD/compile-pentium64-debug-max, or remove the $static_link, or add --with-zlib-dir=bundled.
Still, it is a bug in configure.in that it wrongly decides to use the system libz when that doesn't actually work when trying to link. It should use the same flags when detecting libz as when actually linking the mysqld and other binaries.
So actually the libz check needs to do check 3 different linker options (plain, adding --with-mysqld-ldflags, and adding --with-client-ldflags), and only if system libz works in all three cases should it use that in preference to the bundled.
I'll see if I can come up with a patch for this at some point, I may ask you to test it later.
(Not sure how important this is. Linking mysqld statically was used historically, but these days there are so many problems with fully static binaries that it does not really work anymore. Still, I would like to get it fixed, I strongly favour ./configure just doing the right thing, MariaDB should compile out of the box on as many systems as possible).