When emerging totem-1.0.4 on two of my Gentoo boxes, the builds fail in the same place on both machines. It's on totem-disc.c. The compile complains about syntax errors in /usr/include/netinet/in.h; Googling for this comes up with a very similar error when building GARNOME, which is supposedly caused by junky RH9 kernel headers. I'm running linux-headers-2.4.22-r1, and glibc-2.3.5-r1 on both boxes (with different actual kernels; one's vanilla- and one's gentoo-, but both are 2.4.) Reproducible: Always Steps to Reproduce: 1. emerge totem 2. Wait ... 3. Fail! Actual Results: gcc bombs with the following errors: === In file included from /usr/include/netdb.h:28, from /usr/include/gnome-vfs-2.0/libgnomevfs/gnome-vfs-address.h:31, from /usr/include/gnome-vfs-2.0/libgnomevfs/gnome-vfs.h:28, from totem-disc.c:69: /usr/include/netinet/in.h:354: error: syntax error before '(' token /usr/include/netinet/in.h:354: error: syntax error before "__u32" /usr/include/netinet/in.h:355: error: syntax error before '(' token /usr/include/netinet/in.h:355: error: syntax error before "__u16" /usr/include/netinet/in.h:357: error: syntax error before '(' token /usr/include/netinet/in.h:357: error: syntax error before "__u32" /usr/include/netinet/in.h:359: error: syntax error before '(' token /usr/include/netinet/in.h:359: error: syntax error before "__u16" make[2]: *** [totem-disc.lo] Error 1 make[2]: Leaving directory `/var/tmp/portage/totem-1.0.4/work/totem-1.0.4/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/totem-1.0.4/work/totem-1.0.4' make: *** [all] Error 2 === Expected Results: totem should've compiled successfully. As said before, the machines are both 2.4 kernels running the same releases of linux-headers and glibc. emerge info: === Portage 2.0.51.22-r2 (default-linux/x86/2005.0/2.4, gcc-3.3.5-20050130, glibc-2.3.5-r1, 2.4.30 i686) ================================================================= System uname: 2.4.30 i686 Intel(R) Pentium(R) 4 CPU 2.40GHz Gentoo Base System version 1.6.13 ccache version 2.3 [enabled] dev-lang/python: 2.3.5 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.4.22-r1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium4 -O3 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium4 -O3 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.lsu.edu" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/opt/portage-overlay" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X aalib alsa apm arts avi berkdb bitmap-fonts bonobo cdr crypt cups curl dga dvd eds emboss encode esd fam flac foomaticdb fortran gd gdbm ggi gif glut gnome gpm gstreamer gtk gtk2 gtkhtml guile imagemagick imlib ipv6 java jpeg ldap libg++ libwww lua mad mikmod mmx motif mozilla mp3 mpeg ncurses nls offensive ogg oggvorbis opengl oss pam pdflib perl png python qt quicktime readline samba sdl slang spell sse sse2 ssl tcltk tcpd tiff truetype truetype-fonts type1-fonts unicode vorbis xine xml xml2 xmms xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS ===
could you provide a preparsed file (repeat the last gcc command that fails, just add -E (I think it is) and upload it here). This way, we don't need to have the excact samt include files as you have in order to pinpoint the source of the problem.
Created attachment 66944 [details] gcc ... -E output for the command that fails. This is a compressed version of the gcc ... -E output for the command that fails. Don't mind the fact that the decompressed version is totem-disc.o; that's just because I really didn't change the command at all other than adding -E. :)
I realized that I left out the gcc command that's causing the issue. D'oh. Here it is: === i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I.. -D_REENTRANT -I.. -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -DORBIT2=1 -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/freetype2/config -I/usr/include/libgnomeui-2.0 -I/usr/include/libgnome-2.0 -I/usr/include/libgnomecanvas-2.0 -I/usr/include/libart-2.0 -I/usr/include/gconf/2 -I/usr/include/libbonoboui-2.0 -I/usr/include/orbit-2.0 -I/usr/include/libbonobo-2.0 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/bonobo-activation-2.0 -I/usr/include/libxml2 -I/usr/include/libglade-2.0 -I/usr/include/gnome-vfs-module-2.0 -I/usr/include/gnome-desktop-2.0 -I/usr/include/startup-notification-1.0 -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -I/usr/include/libnautilus-burn -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/freetype2/config -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -DORBIT2=1 -pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/freetype2/config -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/gconf/2 -I/usr/include/orbit-2.0 -I/usr/include/nautilus -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/bonobo-activation-2.0 -I/usr/include/libbonobo-2.0 -DGNOMELOCALEDIR=\"/usr/share/locale\" -DGCONF_PREFIX=\"/apps/totem\" -DDATADIR=\"/usr/share\" -DLIBEXECDIR=\"/usr/libexec\" -DLOGO_PATH=DATADIR\"\"G_DIR_SEPARATOR_S\"totem\"G_DIR_SEPARATOR_S\"totem_logo.png\" -Wall -Wchar-subscripts -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wcast-align -Wsign-compare -fno-strict-aliasing -march=pentium4 -O3 -pipe -MT totem-disc.lo -MD -MP -MF .deps/totem-disc.Tpo -c totem-disc.c -fPIC -DPIC -o .libs/totem-disc.o === Sorry about that!
For me the high level dependency that wasn't being met was gst-plugins-flac.
Probably this is the same problem as in bug #68087.
yep, I'm pretty sure it's the same problem: I got the same error message and after upgrading from linux-headers-2.4.x to linux-headers-2.6.y (as advised in that bug report) totem compiled just fine. So I guess it's just a case of adding a ">=linux-headers-2.6" as a dependency...
(In reply to comment #6) > So I guess it's just a case of adding a ">=linux-headers-2.6" as a dependency... That's not much of a solution for those of us who use 2.4. I'm going to try the -D_NETINET_IN_H trick and see if that still works ... Sure enough, that seems to do it.
I'm on a 2.4-only system and I've run into this behavior as well. The -D_NETINET_IN_H trick worked for me.
*** Bug 119265 has been marked as a duplicate of this bug. ***
I will brashly assume that this bug probably doesn't apply any more. Guys?
Well, I have migrated to 2.6 at both home and work. So I am not seeing the problem anymore. But I don't know whether the problem still exists.
reporter says it works for him now, this is most likely fixed by now in recent versions. Please re-open if this is not the case, thanks.