RE: [png-mng-implement] SOLVED(?): failed to load "./stock_about_16.png": Couldn't recognize the image file format
- From: John Bowler <jbowler acm org>
- To: <png-mng-implement lists sourceforge net>, <gtk-devel-list gnome org>
- Subject: RE: [png-mng-implement] SOLVED(?): failed to load "./stock_about_16.png": Couldn't recognize the image file format
- Date: Wed, 24 May 2006 17:06:51 -0700
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
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
>"deep linking" like this is bad:
>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>
] [Thread Prev