Hi everyone,
I am trying to compile Gnome via Gargnome (garnome-2.14.3). Everything goes smooth till this message:
--------------------------------
checking for doxygen... /usr/bin/doxygen
checking whether to build Doxygen documentation... yes
checking for pgoff_t... no
checking for BLKGETSIZE64... no
configure: error: BLKGETSIZE64 is not defined
--------------------------------
Browsing the web and other LQ messages it seems to me that the problem lays in the kernel headers. Common suggestion is to installing Linux-Libc-Headers.
Could someone please explain where to get those headers for Ker 2.6.17 if there are any of course. The ones I found are for ker 2.6.12. Will they do for ker 2.6.17 as well?

Thanks for any help,
Pier

This may be of help.

"Infact, the updated patch is included with GARNOME 2.12.1 and above, you just need to uncomment it in the freedesktop/hal/Makefile before starting your build."

http://bugzilla.gnome.org/show_bug.cgi?id=312775

Here is the Makefile section:

/garnome-2.14.3/freedesktop/hal/Makefile

# [slackware / suse fix] uncomment the following line to fix defines that are not included in your distribution.
#PATCHFILES += hal-kernel-includes.diff

Thank you very much!
That solved the "BLKGETSIZE64" problem. Yet another one cropped up though:
---------------------------
probe-input.c:48: error: redefinition of `struct input_id'
shared.h:62: warning: `drop_privileges' defined but not used
make[15]: *** [probe-input.o] Error 1
---------------------------

Thank you for any help,
Pier

Hum, the diff has the change for that error, I don't know why it didn't compile:

+/* struct input_id is not defined in Slackware */
+struct input_id {
+ __u16 bustype;
+ __u16 vendor;
+ __u16 product;
+ __u16 version;
+};

As Pat said in the 10.2 stable changelog when he removed GNOME:

"... GNOME is and always has been a moving target (even the "stable" releases usually aren't quite ready yet) that really does demand a team to keep up on all the changes (many of which are not always well documented). ...

http://www.slackware.com/changelog/stable.php?cpu=i386

Kludges are never an elegant solution.

This is the problem with Slackware using "Stable" kernel headers. Well, there not so stable actually. Most programs now-a-days are using the 2.6 system calls...

evdev in xorg-drivers (7.x) will bomb with 2.4 headers and there doesn't seem to be an easy way around it on a stock system. Here's hoping Pat will jump on the band wagon soon otherwise this will be a continuing problem more often as time passes.

With kernel 2.6.18, we now have "make headers_install" which sanitizes and installs headers straight from the kernel tarball... Just in the nick of time seeing as how the LLH project is now dead. This is what Pat will be using if and when he "deems 2.6 to be stable enoungh".....

It would have been nice if glibc-2.3.6 were compiled against 2.6 headers when he first uploaded it to current. A massive portion of Slackware has been recompiled against said glibc in the past few months, judging from the changelog. But everything is still unaware of 2.6......

find configure.in in the top level dir : /tmp/hal-0.5.7.1/configure.in

this is the old code, here you have to remove two lines :

#include <linux/ioctl.h>
#include <linux/fs.h>],

and replace it by : #include <sys/mount.h>],

part of old configure.in:

# Check for BLKGETSIZE64
AC_CHECK_TYPE(pgoff_t, ,
[AC_DEFINE(pgoff_t, unsigned long, [Index into the pagecache])],
/usr/include/sys/types.h)
AC_MSG_CHECKING(for BLKGETSIZE64)
AC_TRY_COMPILE(
[#include <sys/types.h>
#include <linux/ioctl.h>
#include <linux/fs.h>],
[int main(int argc, char *argv[])
{
int fd = 0;
unsigned long long int n;
ioctl (fd, BLKGETSIZE64, &n);
return 0;
}
], have_size64=yes, have_size64=no)
AC_MSG_RESULT($have_size64)
if test x$have_size64 = xno; then
case "$host" in
*-*-linux*)
AC_MSG_ERROR([BLKGETSIZE64 is not defined])
;;
*)
;;
esac
fi

this is the new code with the line :" #include <sys/mount.h>], " included.

Part of new configure.in:

# Check for BLKGETSIZE64
AC_CHECK_TYPE(pgoff_t, ,
[AC_DEFINE(pgoff_t, unsigned long, [Index into the pagecache])],
/usr/include/sys/types.h)
AC_MSG_CHECKING(for BLKGETSIZE64)
AC_TRY_COMPILE(
[#include <sys/types.h>
#include <sys/mount.h>],
[int main(int argc, char *argv[])
{
int fd = 0;
unsigned long long int n;
ioctl (fd, BLKGETSIZE64, &n);
return 0;
}
], have_size64=yes, have_size64=no)
AC_MSG_RESULT($have_size64)
if test x$have_size64 = xno; then
case "$host" in
*-*-linux*)
AC_MSG_ERROR([BLKGETSIZE64 is not defined])
;;
*)
;;
esac
fi

Hope this helps you ...

Typically when you run into one of these "old headers" issues, there's only a few things to consider, and if it's fixable, the fix is actually quite easy.

The big one is "Is this code accessing a kernel module?" Several kernel modules have changed their APIs between 2.4.x and 2.6.x. If the answer to this is yes, you're in good shape.

After that is whether or not the application has done any checking to see what kernel is present. If it did, and it detected 2.4.x, you could easily have problems if the APIs are different and the app is now expecting a 2.4.x kernel elsewhere.

Considering that the majority of the reasons for keeping the kernel headers that were present when glibc was built have to do with workarounds for kernelspace issues, cherry picking for specific new headers isn't terribly dangerous.

The "cheat" is very simple. If it's a missing header complaint, go into the file that wants the header and change the include statement to read "/usr/src/linux/include/linux/foo.h" instead of just <linux/foo.sh>. If it's a missing structure or element, check carefully in both versions of the header files to find out where that item is actually supposed to come from, and then make sure that it doesn't in turn #include something else incompatible from the 2.6.x headers.

This works for USB input drivers (which underwent an API change, much to my irritation), as well as some issues with compiling Video4Linux-2 tools (like ivtv).

I tired to fix BLKGETSIZE64 error as described above, but got no success. May be there are some more changes necessary. I am runnign fresh Slack 11.

actually, the same must be done in the configure (!!!) also.

then it seems possible to compile hal-0.5.8.1

Mentioned cure is not very helpful as during the compilation process dies at:

make[6]: Entering directory `/data/src/programs/00-system/hal/hal-0.5.8.1/hald/linux/probing'
if gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -DPACKAGE_SYSCONF_DIR=\""/etc"\" -DPACKAGE_DATA_DIR=\""/usr/share"\" -DPACKAGE_BIN_DIR=\""/usr/bin"\" -DPACKAGE_LOCALE_DIR=\""/usr/share/locale"\" -DPACKAGE_LOCALSTATEDIR=\""/var"\" -I../../.. -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -O3 -pipe -march=i686 -mtune=i686 -Wall -Wchar-subscripts -Wmissing-declarations -Wnested-externs -Wpointer-arith -Wcast-align -Wsign-compare -MT probe-input.o -MD -MP -MF ".deps/probe-input.Tpo" -c -o probe-input.o probe-input.c; \
then mv -f ".deps/probe-input.Tpo" ".deps/probe-input.Po"; else rm -f ".deps/probe-input.Tpo"; exit 1; fi
probe-input.c: In function `main':
probe-input.c:150: error: storage size of 'id' isn't known
probe-input.c:192: error: `BUS_HOST' undeclared (first use in this function)
probe-input.c:192: error: (Each undeclared identifier is reported only once
probe-input.c:192: error: for each function it appears in.)
probe-input.c:150: warning: unused variable `id'

configure options used:
./configure --prefix=/usr \
--sysconfdir=/etc \
--localstatedir=/var \
--disable-policy-kit \
--with-os-type=slackware \
--without-macbookpro \
--with-system-pid-file=/var/run/hal/pid

Any ideas?