GNOME Bugzilla – Bug 674064
fails to build on (k)freebsd: procproperties.cpp:27:23: fatal error: asm/param.h: No such file or directory
Last modified: 2013-02-04 23:37:28 UTC
Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=665999 gnome-system-monitor 3.4.0 fails to build on non-Linux plattforms. g++ -DHAVE_CONFIG_H -I. -I.. -DPROCMAN_DATADIR=\""/usr/share/procman/"\" -DGNOMELOCALEDIR=\""/usr/share/locale"\" -DDATADIR=\""/usr/share"\" -DGSEAL_ENABLE -pthread -I/usr/include/glib-2.0 -I/usr/lib/x86_64-kfreebsd-gnu/glib-2.0/include -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/gtk-3.0 -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/atk-1.0 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/giomm-2.4 -I/usr/lib/x86_64-kfreebsd-gnu/giomm-2.4/include -I/usr/include/gtk-3.0/unix-print -I/usr/include/glibmm-2.4 -I/usr/lib/x86_64-kfreebsd-gnu/glibmm-2.4/include -I/usr/include/librsvg-2.0 -I/usr/include/libgtop-2.0 -I/usr/include/libwnck-3.0 -I/usr/include/startup-notification-1.0 -I/usr/include/gtkmm-3.0 -I/usr/lib/gtkmm-3.0/include -I/usr/include/atkmm-1.6 -I/usr/include/pangomm-1.4 -I/usr/lib/pangomm-1.4/include -I/usr/include/cairomm-1.0 -I/usr/lib/cairomm-1.0/include -I/usr/include/gdkmm-3.0 -I/u sr/lib/gdkmm-3.0/include -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/libxml2 -DGSM_DATA_DIR=\""/usr/share/gnome-system-monitor"\" -D_FORTIFY_SOURCE=2 -Wall -std=c++98 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -Wall -c -o gnome_system_monitor-procproperties.o `test -f 'procproperties.cpp' || echo './'`procproperties.cpp procproperties.cpp:27:23: fatal error: asm/param.h: No such file or directory compilation terminated. make[3]: *** [gnome_system_monitor-procproperties.o] Error 1 make[3]: Leaving directory `/build/buildd-gnome-system-monitor_3.4.0-1-kfreebsd-amd64-RIgfIa/gnome-system-monitor-3.4.0/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/build/buildd-gnome-system-monitor_3.4.0-1-kfreebsd-amd64-RIgfIa/gnome-system-monitor-3.4.0' make[1]: *** [all] Error 2 make[1]: Leaving directory `/build/buildd-gnome-system-monitor_3.4.0-1-kfreebsd-amd64-RIgfIa/gnome-system-monitor-3.4.0' make: *** [debian/stamp-makefile-build] Error 2 https://buildd.debian.org/status/fetch.php?pkg=gnome-system-monitor&arch=kfreebsd-amd64&ver=3.4.0-1&stamp=1332869043 Attached is a patch from Christoph Egger <christoph@debian.org>
Created attachment 212006 [details] [review] [PATCH] Fix time accounting for (k)freebsd
Thanks for the patch. However, the OpenBSD got to this first. see https://bugzilla.gnome.org/show_bug.cgi?id=673146 & commit 94be681c1 in master. Does it work for you to just add " || defined(__FreeBSD__) || defined(__FreeBSD_kernel__)" to the end of their checks. A quick confirmation would be appreciated as I'd like to get this into the 3.4.1 release tonight.
(In reply to comment #2) > A quick confirmation would be appreciated as I'd like to get this into the > 3.4.1 release tonight. I've forwarded this question to Christoph Egger, the original author of this patch (and one of our kfreebsd porters)
Test compiling 3.4.1 on kfreebsd was not successful. I get the following error message: procproperties.cpp: In function 'void fill_proc_properties(GtkWidget*, ProcInfo*)': procproperties.cpp:123:32: error: 'nitems' was not declared in this scope I can't find a definition of ntimes in the header files of the kfreebsd VM, so this looks like it is something openBSD specific
Created attachment 212223 [details] [review] updated patch
changing nitems(mib) to 2 made g-s-m compile on kfreebsd, but the values shown in the properties tab did not match the "top" output. Changing HZ = (cinf.stathz ? cinf.stathz : cinf.hz); fixed that. Updated patch based on 3.4.1 attached.
In the latest trunk nitems has been replaced with G_N_ELEMENTS, so changing it to 2 should not be required, the only thing required is the "HZ = (cinf.stathz ? cinf.stathz : cinf.hz);", but we should get the OpenBSD guys check if that's OK for them too.
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.