rm -f .libs/subshell.lo i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -D_XOPEN_SOURCE=500 -DXTHREADS -DXUSE_MTSAFE_API -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/opt/fdo//include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/X11R6/include -I/usr/include/freetype2 -I/usr/include/freetype2/config -I/usr/include/libart-2.0 -DGNOMEZVTLIBDIR=\"/usr/lib\" -DGNOMEZVTDATADIR=\"/usr/share\" -DGNOMEZVTPIXMAPDIR=\"/usr/share/pixmaps\" -DGNOMEZVTBINDIR=\"/usr/bin\" -DGNOMEZVTLOCALSTATEDIR=\"/var/lib\" -DGNOMEZVTLOCALEDIR=\"\" -DGTK_VERSION=\"\" -DG_LOG_DOMAIN=\"ZVT\" -DPTY_HELPER_DIR=\"/usr/libexec/libzvt-2.0\" -DG_DISABLE_DEPRECATED -DGDK_DISABLE_DEPRECATED -DGDK_PIXBUF_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED -O2 -march=pentium4 -fomit-frame-pointer -pipe -c subshell.c -fPIC -DPIC -o .libs/subshell.lo In file included from subshell.c:25: subshell-includes.h:6:1: warning: "_XOPEN_SOURCE" redefined <command line>:2:1: warning: this is the location of the previous definition subshell.c: In function `receive_fd': subshell.c:123: error: `caddr_t' undeclared (first use in this function) subshell.c:123: error: (Each undeclared identifier is reported only once subshell.c:123: error: for each function it appears in.) subshell.c:123: error: parse error before "cmptr" make[2]: *** [subshell.lo] Error 1 make[2]: *** Waiting for unfinished jobs.... Here's some more details on the environment: CFLAGS="-O2 -march=pentium4 -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" MAKEOPTS="-j2" I'm using GCC of i686-pc-linux-gnu-3.4.3, but have also tried 3.3.4. It seems to be some issue with caddr_t and I would suspect a bad include file, but it all looks good to me. Reproducible: Always Steps to Reproduce: 1. emerge libzvt Actual Results: emerge filed
can't reproduce, looks to be a glibc issue. What glibc are you using, it should probably define the erroring type.
It's glibc 2.3.4.20041102 I have the same glibc on another machine and the same version of libzvt compiles just fine. I've tried re-emerging glibc and it doesn't seem to help.
I'm not sure why this doesn't get defined properly after looking at all the includes, but the machine that it emerged on properly can't emerge it now either, so perhaps it upgraded to this version of libc AFTER compiling that version of libzvt, so perhaps libzvt won't compile against the new one.
have you resolved this issue or is there a need to continue looking into this?
closing as wontfix, due to inactivity by the reporter, and age of the bug. reopen if its still an issue.
