SOLVED(?): failed to load "./stock_about_16.png": Couldn't recognize the image file format

There have been numerous reports of the following error:

failed to load "./stock_about_16.png": Couldn't
recognize the image file
format
for file './stock_about_16.png'

from people compiling gtk+ on various platforms (see
bugzilla 108718 and
102142).  I got the error on Solaris9, and a little digging
revealed
that my .loaders file listed all of the loaders except png. 
Running
'make gdk-pixbuf.loaders' manually showed a missing
symbol/relocation
error when trying to load libpixbufloader-png.so.

Short version: LIBPNG was '-L/path/to/lib -lpng12' but
needed to be
'-L/path/to/lib -lpng12 -lz' because my libpng was shared,
and linked
against a shared zlib.  Unless -lz is explicitly linked as a
dependency
when compiling 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.  Only the direct dependencies of
libpixbufloader-png.so are loaded with it, and not the
third-level ones.

However, building libpixbufloader-png.so with an explicit
link
dependency on -lz should NOT be necessary:
libpixbufloader-png.so
doesn't use zlib directly.  And, "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).  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.  In the latter case...see above.

I don't have a universal non-ugly solution to the general
problem -- but
I wanted to at least record this workaround for the next
person who ran
into this error with gtk+:

Manually add -lz to LIBPNG in the gdk-pixbuf/Makefile.

--
Chuck
--
  Charles Wilson
  cygwin at removespam cwilson dot fastmail dot fm



-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the
Cost and Risk!
Fully trained technicians. The highest number of Red Hat
certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/
sel?cmd=lnk&kid=107521&bid=248729&dat=121642
_______________________________________________
png-mng-implement mailing list
png-mng-implementlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/png-m
ng-implement

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 <jbowleracm.org>



-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the
Cost and Risk!
Fully trained technicians. The highest number of Red Hat
certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/
sel?cmd=lnk&kid=107521&bid=248729&dat=121642
_______________________________________________
png-mng-implement mailing list
png-mng-implementlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/png-m
ng-implement