GNOME Bugzilla – Bug 108718
Fix for bug 102142 - failed to load "./stock_add_16.png" didn't take?
Last modified: 2009-06-04 21:39:38 UTC
The bug entry for 102142 about being unable to load stock_add_16.png mentions a target of 2.2.1 for resolution. It would seem that 2.2.1 still has issues with being unable to load that file: make[2]: Entering directory `/home/raj/gtk+-2.2.1/gtk/stock-icons' GDK_PIXBUF_MODULE_FILE=../../gdk-pixbuf/gdk-pixbuf.loaders ../../gdk-pixbuf/gdk-pixbuf-csource \ --raw --build-list stock_add_16 ./stock_add_16.png stock_add_24 ./stock_add_24.png stock_align_center_16 ./stock_align_center_16.png stock_align_center_24 ./stock_align_center_24.png stock_align_justify_16 ./stock_align_justify_16.png stock_align_justify_24 ./stock_align_justify_24.png stock_align_left_16 ./stock_align_left_16.png stock_align_left_24 ./stock_align_left_24.png stock_align_right_16 ./stock_align_right_16.png stock_align_right_24 ./stock_align_right_24.png stock_apply_20 ./stock_apply_20.png stock_cancel_20 ./stock_cancel_20.png stock_dnd_multiple_32 ./stock_dnd_multiple_32.png stock_bottom_16 ./stock_bottom_16.png stock_bottom_24 ./stock_bottom_24.png stock_cdrom_16 ./stock_cdrom_16.png stock_cdrom_24 ./stock_cdrom_24.png stock_clear_24 ./stock_clear_24.png stock_close_20 ./stock_close_20.png stock_close_24 ./stock_close_24.png stock_colorselector_24 ./stock_colorselector_24.png stock_color_picker_25 ./stock_color_picker_25.png > ./gtkstockpixbufs.h || \ ( rm -f ./gtkstockpixbufs.h && false ) failed to load "./stock_add_16.png": Couldn't recognize the image file format for file './stock_add_16.png' make[2]: *** [gtkstockpixbufs.h] Error 1 This is under HP-UX 11.11 with the HP ANSI C compiler, using gnumake: # which make /usr/local/bin/make # make -v GNU Make 3.80 Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Really hard to say. Is SOEXT getting set correctly in gdk-pixbuf/queryloaders.c? If so, it's probably something else, but I can't tell what it is from the above.
*** Bug 133197 has been marked as a duplicate of this bug. ***
So, this turned out to be a tricky one, but I've solved it. I've built my libjpeg, libz, libtiff & libpng myself. They're all built like shared libraries, and they live in /gnome-2.6-home/lib. However, I had to manually create the .la-files for libtool. If You wan't to, I can attach them later. Then the makefiles have to be manipulated (Don't know why it doesn't work as it should, but I have to add -L./.libs on several LINK=$(LIBTOOL)... lines). Finally, I have to add SHLIB_PATH = $LD_LIBRARY_PATH (in gar.conf.mk), and also in the following Makefiles. gtk+/work/main.d/gtk-2.3.2/gdk-pixbuf/Makefile : gdk-pixbuf.loaders: $(loader_LTLIBRARIES) gdk-pixbuf-query-loaders LOADERS=`echo libpixbufloader-*.la` ; \ SHLIB_PATH=`echo SHLIB_PATH:/alcesys/build/garnome-0.29.1/platform/gtk+/work/main.d/gtk+-2.3.2/gdk-pixbuf/.libs` ; \ gtk+/work/main.d/gtk-2.3.2/gtk/stock-icons/Makefile : pixbuf_csource = SHLIB_PATH=`echo $SHLIB_PATH:/alcesys/build/garnome-0.29.1/platform/gtk+/work/main.d/gtk+-2.3.2/gdk-pixbuf/.libs` GDK_PIXBUF_MODULE_FILE=$(top_builddir)/gdk-pixbuf/gdk-pixbuf.loaders $(top_builddir)/gdk-pixbuf/gdk-pixbuf-csource
Don't think the last comment is related to the problem that the original reporter was having.
Well, I certainly got the exact same error-message. I'm almost sure that if the original reporter tries to run the 'gdk-pixbuf-csource' on his HP-UX machine, he will see that it: a) won't start at all since it can't find the libs it needs, at least not until it's installed b) won't recognize any file-types, (unless he has built shared libs for jpeg, tiff etc) and made sure that the .la-files actually mention these sl-files that are needed A very easy way of seing that is to use `ldd'. I'm 99% sure that when the config.log is examined, he'll find that no modules for handling the graphics were built.
Putting myself into CC.
Last change was to put myself in CC. Should have added commetns as well, sorry ya'll are gonna get two emails on my account. I think Jonas is onto something. I'm getting the same problem on a Solaris 2.6 box with tiff, jpeg, and png compiled myself and in non-standard places (i.e. /usr/usc/png/1.2.5/). It is true that lt-gdk-pixbuf-csource doesn't seem to have png/tiff/jpeg built into it, so that's why I believe this seems to be the corrent line of solution. I'm trying to impliment a similar solution... I'm pretty sure the SHLIB stuff is hp-ux specific. So I went into gdk-pixbuf/Makefile and added the -L./.libs to the LINK= line and did a 'gmake clean; gmake' and now I get: g_module_open() failed for /auto/src-01/common/usc/gnu/gtk+/gtk+-2.2.3/gdk-pixbuf/libpixbufloader-png.la: ld.so.1: /auto/src-01/common/usc/gnu/gtk+/gtk+-2.2.3/gdk-pixbuf/.libs/lt-gdk-pixbuf-query-loaders: fatal: relocation error: file /usr/usc/png/1.2.5/lib/libpng.so.3: symbol inflateReset: referenced symbol not found Which I'm confused about. png 1.2.5 is the latest, and it was compiled with the same compiler. I've been playing with this for 3 weeks. I actually had to hard code the '-L/usr/usc/png/1.2.5/lib' into the configure.in file because the configure script couldn't find it with --with-libpng= even if I set LDFLAGS... This is the last of *many* problems I've had trying to get gtk+2 to compile... Phil
Mass changing gtk+ bugs with target milestone of 2.4.2 to target 2.4.4, as Matthias said he was trying to do himself on IRC and was asking for help with. If you see this message, it means I was successful at fixing the borken-ness in bugzilla :) Sorry for the spam; just query on this message and delete all emails you get with this message, since there will probably be a lot.
*** Bug 142027 has been marked as a duplicate of this bug. ***
I may have find a way to resolve this problem ... at least on HPUX 10.20. I had the same error message until I finally investigate more on libpng. 1) In the Makefile on libpng it is specified to use the same options has zlib uses. 2) Tiff and jpeg had both .a (static) ans .sl (shared libs) but zlib and png only had static (.a) files under their /opt/*/lib/* Here is my system: Everything is under /opt/Whatever/ I've built successfully: binutils 2.15 GCC 3.4.2 gettext 0.11.5 libiconv 1.9.2 jpeg-6b tiff-3.6.1 expat-1.95.8 xft 2.1.2 freetype 2.1.9 fontconfig 2.2.3 xcursor 1.0.2 xrender 0.8.3 Here is how I made gtk+ working properly: 1) I've recompiled zlib 1.2.1 with the option --shared 2) I've used makefile.hpux from libpng and modified it so that CFLAGS and CCFLAGS would be the same has zlib's Makefile: CC=gcc CFLAGS=-I$(ZLIBINC) -fPIC -O3 -DUSE_MMAP CCFLAGS=-I$(ZLIBINC) -fPIC -O3 -DUSE_MMAP and remove the +z from: $(CC) -c $(CFLAGS) -o $@ $*.c #$(CC) -c $(CFLAGS) +z -o $@ $*.c and ran 'gmake' then 'gmake install' 3) Recompiled glib, atk and pango Note: I've always included in CPPFLAGS and LDFLAGS and/or PKG_CONFIG_PATH what was missing from the configure portion I have then tried once again gtk+-2.4.10 and it passed through stock-icons portion. Here was my environment before building: export CPPFLAGS="-I/opt/gettext/include -I/opt/expat/include -I/opt/tiff/include -I/opt/jpeg/include -I/opt/zlib/include -I/opt/libpng/include" export LDFLAGS="-L/opt/gettext/lib -L/opt/expat/lib -L/opt/tiff/lib -L/opt/jpeg/lib -L/opt/zlib/lib -L/opt/libpng/lib" export PKG_CONFIG_PATH="/opt/glib/lib/pkgconfig/:/opt/xft/lib/pkgconfig/:/opt/freetype/lib/pkgconfig/:/opt/fontconfig/lib/pkgconfig/:/opt/pango/lib/pkgconfig/:/opt/atk/lib/pkgconfig/:/opt/xcursor/lib/pkgconfig/:/opt/xrender/lib/pkgconfig/" Note that I had to rename /usr/include/X11 to /usr/include/X11.orig then make a symlink between /usr/include/X11 -> /usr/include/X11R6 because even if I was specifying the lib and include path it was still searching into /usr/include/X11 instead of /usr/include/X11R6/ then ran the configure: ./configure --prefix=/opt/gtk+-2.4.9 --disable-glibtest --disable-threads --x-includes=/usr/include/X11R6/X11 --x-libraries=/usr/lib/X11R6 Hoping this heps!
I think that simply adding the information in a README.hpux (or what ever) about the fact that it's important to make sure that zlib and libpng uses the same compilations options (CFLAGS and CCFLAGS), not use +z option (at least with gcc) and use --shared option for zlib would be enough. With a final touch saying: For more info please read the makefile.hpux of libpng for more compatibility informations. Maybie a check could be done in the ./configure of every packages? At least the first one, glib? - vin
Is this still an issue in gtk+ 2.12 or later, or can this be closed as OBSOLETE?
I assume it's OBSOLETE by now. If not, feel free to reopen.