All I can say: You are dead on! Here's the output: when building I get:
make[3]: autogen: Command not found make[3]: [gui_property.h] Error 127 (ignored) touch gui_property_priv.h gui_property.c gui_property.h make[3]: Leaving directory `/homedir/RPM/BUILD/gtk-gnutella-0.96b/src/if' Continuing in src... gcc -c -I.. -I. -I/usr/include/gtk-1.2 -I/usr/X11R6/include -I/usr/include/glib-1.2 -I/usr/lib64/glib/include -I/usr/include/libxml2 -DCURDIR=src -O2 -pipe -Wall -W -Wall -Wformat=2 main.c main.c: In function `main': main.c:882: error: duplicate case value main.c:882: error: previously used here main.c:883: error: duplicate case value main.c:883: error: previously used here make[2]: *** [main.o] Error 1 make[2]: Leaving directory `/homedir/RPM/BUILD/gtk-gnutella-0.96b/src' make[1]: *** [subdirs] Error 1 make[1]: Leaving directory `/homedir/RPM/BUILD/gtk-gnutella-0.96b' make: *** [all] Error 2 The grepping operations reveal: on glib-1.2: $ grep 'typedef.*size' /usr/include/glib-1.2/glib.h typedef gint32 gssize; typedef guint32 gsize; on glib-2.0: $ grep 'typedef.*size' /usr/lib64/glib-2.0/include/glibconfig.h typedef signed long gssize; typedef unsigned long gsize; And indeed, building a gtk2 version doesn't have these problems. >From now on, I'll only build gtk2 for x86_64 Thank you for the complete explanation! Hendrik-Jan Christian Biere wrote: > Hendrik-Jan Heins wrote: > >>Yes, my i586 and x86_64 installations are completely separate, not even >>the ~ is shared. >>I think all the correct headers and files were found, as both gtk1 and >>gtk2 builds went just fine after hacking the main.c file. >>All previous builds also went well, no problems whatsoever. >>I don't know how necessary this check is, as gtk-gnutella works fine >>with a build with the check removed... > > > Such bugs do not necessarily cause compiler warnings or even errors. > It can cause integer overflows and these could have all kinds of > effects including harmless crashes, heap overflows, memory corruption > etc. > > >>I'm not sure if this problem also exists in the gtk2 build (I made a >>.spec file, and added this for both builds), but it could also be that >>there IS an issue with Mandriva's glibc? > > > No, it's not an issue with glibc but GLib. Yes, the name similarity > certainly doesn't help. > > >>Is there a way to check whether this (should be/is) a problem? > > > /PATH/TO is probably /usr for you: > > $ grep 'typedef.*size' /PATH/TO/include/glib/glib-1.2/glib.h > typedef gint32 gssize; > typedef guint32 gsize; > > If you get the above on x86_64, there's not much we can do except > either ignoring the issue or just accepting GLib/Gtk+ 1.2 broken on > 64-bit platforms. Another option would be carefully checking > whether anything really relies on "size_t == gsize" but that's > useless effort IMHO. > > The code should compile just fine with GLib 2.x because it has > this issue fixed. It would be nice if you could put the checks > back in for GLib 2.x and confirm this. > > GLib 2.x installs a machine-dependent header file: > $ grep 'typedef.*size' /PATH/TO/lib/glib-2.0/include/glibconfig.h > typedef signed int gssize; > typedef unsigned int gsize; > > You should probably see "long" instead of "int" on x86_64. If > you see "int", that would be a GLib bug. It's an unsolved mystery > why it's not just > > typedef size_t gsize; > typedef ssize_t gssize; > > This way, all platforms suffer just because of a few (if any) > pre-historic platforms that don't have size_t or ssize_t. Just > to repeat myself: This is not an issue in Gtk-Gnutella but GLib. > It's silently hidden/ignored in most other applications. > > Conclusion: Provide a x86_64 build only for GLib/Gtk+ 2.x assuming > that combination compiles fine. > -- Publieke GnuPG sleutel beschikbaar op de volgende keyserver: pgpkeys.mit.edu Public GnuPG key available at keyserver pgpkeys.mit.edu
signature.asc
Description: OpenPGP digital signature
