Summary: | app-admin/gkrellm-2.3.0 compilation issue (fix included) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | behd <colomailbe> |
Component: | Current packages | Assignee: | Jim Ramsay (lack) (RETIRED) <lack> |
Status: | RESOLVED FIXED | ||
Severity: | minor | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
/usr/include/stdio.h (glibc 2.3.6-r3)
/usr/include/bits/stdio.h (glibc 2.3.6-r3) build log gkrellm-2.3.0 |
Description
behd
2008-01-03 17:08:59 UTC
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! |