GNOME Bugzilla – Bug 104664
Wrong versions of files in tar-balls!
Last modified: 2004-12-22 21:47:04 UTC
So, finally I think that I've found out why this *#¤%# doesn't compile on my Solaris system. The problem shown below occurs for many files in the sysdeps/solaris directory when I try to build this thing, and it never works immediately :----( /bin/bash ../../libtool --mode=compile /opt/gnu/gcc-3.2.1/bin/gcc -DHAVE_CONFIG_H -I. -I. -I../.. -D_IN_LIBGTOP -D_GNU_SOURCE -DGLIBTOP_NAMES -I../.. -I../.. -I../../sysdeps/solaris -I../../include -DNEED_GNOMESUPPORT_H -I../../support -I../../support -I/opt/gnome-2.2/include/glib-2.0 -I/opt/gnome-2.2/lib/glib-2.0/include -g -O2 -mcpu=pentium3 -falign-functions=4 -fomit-frame-pointer -funroll-loops -mfancy-math-387 -D_REENTRANT -g -I/opt/gnome-2.2/include -L/opt/gnome-2.2/lib -I/usr/X11R6/include -DGTOPLOCALEDIR=\"/opt/gnome-2.2/share/locale\" -DLIBGTOP_VERSION=\"2.0.1\" -DLIBGTOP_SERVER_VERSION=\"5\" -DLIBGTOP_VERSION_CODE=2000001 -DLIBGTOP_SERVER=\"/opt/gnome-2.2/bin/libgtop_server2\" -I/opt/gnome-2.2/include -g -O2 -mcpu=pentium3 -falign-functions=4 -fomit-frame-pointer -funroll-loops -mfancy-math-387 -D_REENTRANT -g -I/opt/gnome-2.2/include -L/opt/gnome-2.2/lib -c cpu.c /opt/gnu/gcc-3.2.1/bin/gcc -DHAVE_CONFIG_H -I. -I. -I../.. -D_IN_LIBGTOP -D_GNU_SOURCE -DGLIBTOP_NAMES -I../.. -I../.. -I../../sysdeps/solaris -I../../include -DNEED_GNOMESUPPORT_H -I../../support -I../../support -I/opt/gnome-2.2/include/glib-2.0 -I/opt/gnome-2.2/lib/glib-2.0/include -g -O2 -mcpu=pentium3 -falign-functions=4 -fomit-frame-pointer -funroll-loops -mfancy-math-387 -D_REENTRANT -g -I/opt/gnome-2.2/include -L/opt/gnome-2.2/lib -I/usr/X11R6/include -DGTOPLOCALEDIR=\"/opt/gnome-2.2/share/locale\" -DLIBGTOP_VERSION=\"2.0.1\" -DLIBGTOP_SERVER_VERSION=\"5\" -DLIBGTOP_VERSION_CODE=2000001 -DLIBGTOP_SERVER=\"/opt/gnome-2.2/bin/libgtop_server2\" -I/opt/gnome-2.2/include -g -O2 -mcpu=pentium3 -falign-functions=4 -fomit-frame-pointer -funroll-loops -mfancy-math-387 -D_REENTRANT -g -I/opt/gnome-2.2/include -L/opt/gnome-2.2/lib -c cpu.c -fPIC -DPIC -o cpu.lo In file included from ../../glibtop.h:33, from cpu.c:24: glibtop_machine.h:78:8: warning: extra tokens at end of #endif directive In file included from cpu.c:31: glibtop_private.h:68:8: warning: extra tokens at end of #endif directive cpu.c:39: `GLIBTOP_XCPU_FLAGS' undeclared here (not in a function) cpu.c: In function `glibtop_get_cpu_s': cpu.c:84: structure has no member named `xcpu_flags' gmake[4]: *** [cpu.lo] Error 1 gmake[4]: Leaving directory `/usr/mntDir/gnome2build/garnome/garnome/gnome/libgtop/work/libgtop-2.0.1/sysdeps/solaris' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/usr/mntDir/gnome2build/garnome/garnome/gnome/libgtop/work/libgtop-2.0.1/sysdeps' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/usr/mntDir/gnome2build/garnome/garnome/gnome/libgtop/work/libgtop-2.0.1' gmake[1]: *** [all-recursive-am] Error 2 gmake[1]: Leaving directory `/usr/mntDir/gnome2build/garnome/garnome/gnome/libgtop/work/libgtop-2.0.1' make: *** [build-work/libgtop-2.0.1/Makefile] Error 2 ~/garnome/garnome/gnome/libgtop So, I started looking around a little and found out that the files in the include-directory (libgtop-2.0.1/glibtop/include), at least the file cpu.h is ancient! The version of the file provided in the tar-ball is 1.14, but the last version in the cvs-archive is version 1.23 .... How many more of them are there??? What versions of the files should there be in this garball?
I usually 'solve' this little problem by simply replacing each test on the version in the c-files (1001002 -> 2001002) and then compile the stuff. There are other problems too when building this on a Solaris machine, but I'll file a new bug report for those. I looks like (ie I can see that the values changes) if the memory information coming out from the lib works, but the CPU/Process info doesn't work. It would be nice if this would work, since system-monitor as well as the building of applets are affected ..... I checked out the latest version from CVS and compiled & installed it, but as the maintainer of that package knows, it was painful. Gotta clean that mess up when I get back home :-|
How does the patch that is in a different report here work? Should that patch and the older versions in CVS be merged and pulled up to the branch this is being released from now?
*** This bug has been marked as a duplicate of 89432 ***