← Back to team overview

maria-developers team mailing list archive

Re: compile issue and the -lz flag


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

(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

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@xxxxxxxxxxxxxxx> writes:

> Don Kehn <dekehn@xxxxxxxxx> 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).

Follow ups