getline is redefined in client.c while it's already define in stdio.h ### output ### i686-pc-linux-gnu-gcc -mtune=pentium4 -march=pentium4 -mmmx -msse -msse2 -O2 -pipe -fprefetch-loop-arrays -fomit-frame-pointer -momit-leaf-frame-pointer -Wall -I.. `pkg-config --cflags gtk+-2.0 gthread-2.0` -DENABLE_NLS -DLOCALEDIR=\"/usr/share/locale\" -c -o utils.o utils.c client.c:1610: error: conflicting types for 'getline' /usr/include/bits/stdio.h:103: error: previous definition of 'getline' was here client.c:1610: error: conflicting types for 'getline' /usr/include/bits/stdio.h:103: error: previous definition of 'getline' was here make[1]: *** [client.o] Error 1 make[1]: *** Waiting for unfinished jobs.... make[1]: Leaving directory `/var/tmp/portage/app-admin/gkrellm-2.3.0/work/gkrellm-2.3.0/src' make: *** [all] Error 2 * * ERROR: app-admin/gkrellm-2.3.0 failed. * Call stack: * ebuild.sh, line 1701: Called dyn_compile * ebuild.sh, line 1039: Called qa_call 'src_compile' * ebuild.sh, line 44: Called src_compile * gkrellm-2.3.0.ebuild, line 62: Called die * The specific snippet of code: * emake ${TARGET} \ * CC="$(tc-getCC)" \ * INSTALLROOT=/usr \ * INCLUDEDIR=/usr/include/gkrellm2 \ * LOCALEDIR=/usr/share/locale \ * $(use nls || echo enable_nls=0) \ * $(use gnutls || echo without-gnutls=yes) \ * $(use lm_sensors || echo without-libsensors=yes) \ * $(use ssl || echo without-ssl=yes) \ * || die "emake failed" * The die message: * emake failed * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/log/portage/app-admin:gkrellm-2.3.0:20080103-163508.log'. ############## ### fix ### --- src/client.c 2007-07-19 23:45:18.000000000 +0200 +++ src/client.c 2008-01-03 17:39:41.000000000 +0100 @@ -1606,7 +1606,7 @@ static gint -getline(gint fd, gchar *buf, gint len) +mygetline(gint fd, gchar *buf, gint len) { fd_set read_fds; struct timeval tv; ################################## Reproducible: Always Steps to Reproduce: 1. emerge gkrellm 2. 3. Actual Results: compile failure (see description) Expected Results: compile success :p (very easy) fix included (see description).
Curious - I'm not seeing that error here - What libc version provides your stdio.h? Ie, run this: equery belongs /usr/include/bits/stdio.h Thanks!
# equery b /usr/include/bits/stdio.h [ Searching for file(s) /usr/include/bits/stdio.h in *... ] sys-libs/glibc-2.3.6-r3 (/usr/include/bits/stdio.h) # equery b /usr/include/stdio.h [ Searching for file(s) /usr/include/stdio.h in *... ] sys-libs/glibc-2.3.6-r3 (/usr/include/stdio.h) $ ll /usr/include/stdio.h -rw-r--r-- 1 root root 27936 Jun 7 2006 /usr/include/stdio.h $ ll /usr/include/bits/stdio.h -rw-r--r-- 1 root root 5277 Jun 7 2006 /usr/include/bits/stdio.h
Would you mind attaching a copy of both your stdio.h files? In more recent glibc, the 'getline' function should only be seen in stdio.h if you have defined '_GNU_SOURCE', but gkrellm should not be doing this. Also, this patch you submitted doesn't really fix the problem. In fact, I don't think your gkrellm would work in client mode ("gkrellm -s localhost" after you've started /etc/init.d/gkrellmd), since the 'getline' defined in glibc is very different from the one that gkrellm defines. Consider gkrellm's function signature: static gint getline(gint fd, gchar *buf, gint len); Versus the glibc one (from 'man getline'): ssize_t getline(char **lineptr, size_t *n, FILE *stream); So you can't just assume that glibc's version will do what gkrellm is expecting elsewhere in client.c (on lines 1701 and 1717). You would probably get some ugly compiler warnings with your patch as-is. If you changed every instance of 'getline' to 'mygetline' in client.c, this would probably be an okay fix. But I'd rather figure out why your glibc is defining that function when it should not be!
Created attachment 141438 [details] /usr/include/stdio.h (glibc 2.3.6-r3)
Created attachment 141440 [details] /usr/include/bits/stdio.h (glibc 2.3.6-r3)
agreed patch was just to get rid of one of the getline... and as I don't use client/serv arch, I didn't bothered further. NB. just tried gkrellmd + gkrellm to see how it would behave (and of course, gkrellm segfaulted :)
Your stdio.h don't look significantly different from mine. What is the output you get from 'pkg-config --cflags gtk+-2.0 gthread-2.0'? Also, could you please attach your entire build log? The snippet in your problem report doesn't show the commandline used to compile 'client.c'.
# pkg-config --cflags gtk+-2.0 gthread-2.0 -D_REENTRANT -DPNG_NO_MMX_CODE -D_GNU_SOURCE -pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12
Created attachment 141988 [details] build log gkrellm-2.3.0 build log gkrellm-2.3.0
Thanks for the further info! (In reply to comment #8) > # pkg-config --cflags gtk+-2.0 gthread-2.0 > -D_REENTRANT -DPNG_NO_MMX_CODE -D_GNU_SOURCE -pthread -I/usr/include/gtk-2.0 > -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo > -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include > -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 Here is a difference between your system and every other I've tested so far. No one else has '-D_GNU_SOURCE' in their output of the same command. Could you please go into the /usr/lib/pkgconfig directory, and do: grep D_GNU_SOURCE * Perhaps we can see which package exactly is at fault.
# grep D_GNU_SOURCE * direct.pc:Cflags: -D_REENTRANT -I${prefix}/include/directfb -D_GNU_SOURCE directfb-internal.pc:Cflags: -D_GNU_SOURCE -I${prefix}/include/directfb-internal sdl.pc:Cflags: -I${includedir}/SDL -D_GNU_SOURCE=1 -D_REENTRANT $ cat /usr/lib/pkgconfig/sdl.pc # sdl pkg-config source file prefix=/usr exec_prefix=${prefix} libdir=${exec_prefix}/lib includedir=${prefix}/include Name: sdl Description: Simple DirectMedia Layer is a cross-platform multimedia library designed to provide low level access to audio, keyboard, mouse, joystick, 3D hardware via OpenGL, and 2D video framebuffer. Version: 1.2.11 Requires: Conflicts: Libs: -L${libdir} -lSDL -lpthread Cflags: -I${includedir}/SDL -D_GNU_SOURCE=1 -D_REENTRANT $ cat /usr/lib/pkgconfig/gkrellm.pc prefix=/usr Name: GKrellM Description: Extensible GTK system monitoring application Version: 2.3.0 Requires: gtk+-2.0 >= 2.0.0 Cflags: -I/usr/include/gkrellm2
I suspect the issue is that you have build cairo with USE="directfb", which pulls in the directfb library, which sets the dreaded -D_GNU_SOURCE That said, gkrellm-2.3.1 was just released - Would you mind giving it a shot? I'm not that optimistic that it will actually change anything, but I'd like to know if that version is still affected.
as is, install of 2.3.1 failed at the same point. but good investigation ! I upgraded DirectFB to 0.9.25.1 and cairo (still with directfb flag) to 1.5.12, then retried to emerge gkrellm 2.3.1 -> compile flawlessly ! Well done, thanks !
I am closing this now, since the fixed version of DirectFB is stable. Thanks for your help figuring it out!
