When compiling xfcalendar-0.1.6-1.src.rpm, I see this: gcc -O2 -g -o xfcalendar xfcalendar-callbacks.o xfcalendar-interface.o xfcalendar-main.o xfcalendar-support.o xfcalendar-xfce_trayicon.o -Wl,--export-dynamic -Wl,-R/usr/lib64 -L/usr/X11R6/lib64 /usr/lib64/libxfcegui4.so -lXinerama -lXext -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl /usr/lib64/libdbh.so -lm /usr/lib64/libxfce4mcs-client.so -lSM -lICE -lX11 /usr/lib64/libxfce4util.so -lglib-2.0 gdk-pixbuf-csource --raw --build-list \ xfcalendar_icon ./xfcalendar.png > xfcalendar-icon-inline.h failed to load "./xfcalendar.png": Unable to load image-loading module: /usr/lib/gtk-2.0/2.2.0/loaders/libpixbufloader-png.so: /usr/lib/gtk-2.0/2.2.0/loaders/libpixbufloader-png.so: cannot open shared object file: No such file or directory make[2]: *** [xfcalendar-icon-inline.h] Error 1 make[2]: Leaving directory `/scratch/jjensen/rpmbuildspace/BUILD/xfcalendar-0.1.6/src' make[1]: *** [all-recursive] Error 1 Ehem... do I see a case of a hardcoded "/usr/lib" here? Shouldn't "/usr/lib/gtk-2.0/2.2.0/loaders/libpixbufloader-png.so" be "/usr/lib64/gtk-2.0/2.2.0/loaders/libpixbufloader-png.so" ???
Steps to reproduce: rpmbuild --rebuild on an x86_64 machine running x86_64 Linux
Additional information: Looking back, I see that other packages will at least prefer the /usr/lib version of things instead of /usr/lib64. I want a *fully* 64 bit version of all packages... without sneaking in any non lib64 lib requirements.
When I say "other packages will at least prefer the /usr/lib version of things"... I only see this with /usr/lib/gtk-2.0/2.2.0/loaders/libpixbufloader-png.so from the 32 bit gtk2 package. However, when I do "rpm -e gtk2-2.2.4-4.0.i386" and rebuild, the resulting rpm's only report a need for 64bit .so libs: [jjensen@salute x86_64]$ rpm -qp *rpm --requires | grep .so | grep -v "64bit" | wc -l 0 So I think it may just be a case of libpixbufloader-png.so's path being hard-coded. Hope this helps
We really don't hardcode anything; the error is caused by the command: gdk-pixbuf-csource --raw --build-list \ xfcalendar_icon ./xfcalendar.png > xfcalendar-icon-inline.h and "gdk-pixbuf-csource" ships with gtk, so it's the gtk package that is broken, not xfcalendar (although I agree that the header should be provided, so if there is a problem with our package here, it's a missing header) BTW, check your gtk package. Olivier.
can this be closed?
Yes... go ahead and close this. I've entered bugs with Gnome and Red Hat about this: http://bugzilla.gnome.org/show_bug.cgi?id=139987 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120795
Closing. Gtk bug.