I disagree about your view on zlib. Since I am using pre-compiled binaries on Debian there are no .la files . The information is retrieved from pkg-config . Fontconfig indirectly gets loaded by the pkg-config system with our requirement on gtk+2.0 .

On my platform, gtk-+2.0 requires pangoft2 which in turn requires Fontconfig. Fontconfig.pc says:

prefix=/usr
exec_prefix=${prefix}
libdir=${prefix}/lib/i386-linux-gnu
includedir=${prefix}/include

Name: Fontconfig
Description: Font configuration and customization library
Version: 2.8.0
Libs: -L${libdir} -lfontconfig
Libs.private:  -lexpat -lfreetype -lz
Cflags: -I${includedir}

You will note that it correctly has -lz under Libs.private . libfontconfig doesn't directly expose zlib (but it uses it) so it should be in Libs.private . If you were statically linking the application then -lz (and the others) would be dragged in.

On my system glib-2.0.pc doesn't list zlib under "Libs" or "Libs.private", however when I do ldd on libglib-2.0.so I do find it has a dynamic dependency on zlib.

Gibbon has a direct requirement on zlib. We require the library and the dev files (headers) since we include them directly in libsvg/svg.c . I believe that since we are doing this, zlib is our direct dependency and should be treated as such.

I can work around this issue on my platform by doing ./configure LDFLAGS="-lz"    however IMHO I don't think it should be this way.

The first part of the issue looks like a problem in the GNU autotools to me.

Basically we have parser.y and lexer.l, and lexer.l includes parser.h which is generated by compiling parser.y into parser.c.  Therefore lexer.c depends on parser.h, which depends on parser.y.  But that outsmarts GNU autotools.

The real fix to the problem is to add the dependency manually to Makefile.am, so that lexer.o now depends on parser.h.