RE: [png-mng-implement] SOLVED(?): failed to load "./stock_about_16.png": Couldn't recognize the image file format

[John Bowler <jbowler acm org>]

From: Charles Wilson
>Running 'make gdk-pixbuf.loaders' manually showed a missing
>symbol/relocation error when trying to load libpixbufloader-png.so.

>...when libpixbufloader-png.so is dlopened that zlib dependency is
>dropped, and libz.so is not loaded -- so gdk-pixbuf-query-loaders
>gets that missing symbol error for libpixbufloader-png.so.

Right, prior to 1.2.9 anything attempting a *direct* dlopen of
libpng12 without first doing a dlopen of zlib would fail.  IMO this
was clearly wrong, but I doubt whether anything ever did a direct
dlopen("libpng12.so")

It's not so clear that the behaviour in this case is wrong though,
the rules for linking a DLL against libpng are the same as those
for linking an application - all the dependencies must be satisfied
somehow.  The fact that the link of libpixbufloader-png.so succeeds
is, at best, a misfeature of the linker/build system.

The arguments for *not* including -lz in the libpng .so link are just
as good now as they were before, but it doesn't much matter because
the 1.2.9 and 1.2.10 releases both do include -lz when linking the
shared library.

>"deep linking" like this is bad:
>http://lists.debian.org/debian-devel-announce/2005/11/msg00016.html
>which is why the png folks have had a long policy against including
>-lz in their pkg-config --libs output (.pc file).

Which means it won't work with static linking.  libpng-config, on the
other hand, includes -lz when called with --static.

>However, it seems that on some platforms (Solaris, HP?, to judge by
>the error reports) the runtime loader works differently when
>implicitly loading a shared library at application startup, than when
>loading it via dlopen().  In the former case, the lower-level dependency
>gets loaded even tho the app did not link directly against it.  

I guess that's a theoretical possibility, but so far as I am aware
an attempt to link an application against a DLL with unresolved
symbol references fails (e.g. -lpng12 without -lz prior to 1.2.8).

If it doesn't fail the result is unpredictable - somehow the linker
must find the DLL containing the unresolved symbols, without knowing
the name of the DLL...

John Bowler <jbowler acm org>