if I run "make" again after that error it keeps building for some seconds and hits that then:

"...
make[2]: Entering directory `/tmp/gtk/gtk+-2.10.0/demos'
GDK_PIXBUF_MODULE_FILE=../gdk-pixbuf/gdk-pixbuf.loaders ../gdk-pixbuf/gdk-pixbuf-csource --raw --build-list             \
                apple_red  ./apple-red.png      \
                gnome_foot ./gnome-foot.png     \
        > test-inline-pixbufs.h                         \
        || (rm -f test-inline-pixbufs.h && false)
failed to load "./apple-red.png": Couldn't recognize the image file format for file './apple-red.png'
make[2]: *** [test-inline-pixbufs.h] Error 1
make[2]: Leaving directory `/tmp/gtk/gtk+-2.10.0/demos'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/gtk/gtk+-2.10.0'
make: *** [all] Error 2
..."

using --with-included-loaders=png,jpeg is enough to get ride of the png error, and then hits that issue:

"...
../gtk/.libs/libgtk-x11-2.0.a(gtkmarshalers.o): In function `_gtk_marshal_OBJECT__VOID':
/tmp/gtk/gtk+-2.10.0/gtk/gtkmarshalers.c:1160: multiple definition of `_gtk_marshal_OBJECT__VOID'
marshalers.o:/tmp/gtk/gtk+-2.10.0/perf/marshalers.c:58: first defined here
collect2: ld returned 1 exit status
make[3]: *** [testperf] Error 1..."

Looks like Federicos performance framework duplicates some marshallers ?
Can you try just removing the offending marshaller from/perf/marshallers.c ?

that bug is sort of confusing because listing different issues, the first issue described has been fixed by using a different set of build options, might be to close as NOTABUG if you consider that's an user issue due to the set of options used (ie: no loader specified). I've opened bug #346559 about the perf directory issue and will try later and comment on the other bug

I'm reopening this bug for the first build failure Sébastien reported, the gtk.immodules stuff.

(The reason he hit the bug is probably that he tried a static build without the venerable Debian patch collection for Gtk; I'm hitting it because I'm sorting our patches out a little; this dates 2003!)

In modules/input/Makefile.am, there are two gtk.immodules generations: one from the build tree to the installation dir (install-data-hook), and the other local to the build tree (all-local).  The second one is for CVS checkouts builds.

I'll attach a patch which disables the query-immodules call for static linking (exactly like for cross-compiling); this probably fixes the same build failure when cross-compiling.

Created attachment 70903 [details] [review]
Don't query immodules for the local tree when building statically or cross-compiling

Created attachment 70922 [details] [review]
Don't query immodules for the local tree when building statically or cross-compiling v2 (fix typos)

Since the library won't build statically unless --with-included-loaders is specified it would be really nice if attempting to run configure this way would fail with an appropriate error message.

Hmm, but the query-immodules run only fails for --disable-shared builds, no ?

Asking some other way, should this check for DISABLE_SHARED rather than ENABLE_STATIC ?

Oh, right; I understand the question now and I agree: query-modules shouldn't only run if support for modules is enabled / available and when query-modules is built which probably means when DISABLE_SHARED isn't set.

Created attachment 91501 [details] [review]
Don't query immodules for the local tree when cross-compiling or when --disable-shared was given; v3 (check for shared instead of static)

Proposed patch still fails to build due to a similar issue with the perf/ directory, but fixes the reported issue.

Still valid in GTK+ 2.19

Still valid in GTK+ 2.20

Is this still an issue in 2.24 or can this be closed as OBSOLETE?

Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for.
Thanks!