Bugzilla Bug 90489

emerge -u world chokes on sleuthkit-2.01:

x86_64-pc-linux-gnu-gcc -DLINUX2 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -DVER=\"2.01\" -O2 -g   -c -o tsk_endian.o tsk_endian.c
In file included from /usr/include/inttypes.h:28,
                 from tsk_os.h:81,
                 from tsk_endian.c:15:
/usr/include/stdint.h:41: error: conflicting types for 'int64_t'
/usr/include/linux/types.h:139: error: previous declaration of 'int64_t' was here
/usr/include/stdint.h:56: error: conflicting types for 'uint64_t'
/usr/include/linux/types.h:137: error: previous declaration of 'uint64_t' was here
make: *** [tsk_endian.o] Error 1

(I'ld blame the kernel guys for choosing long long over long)

And the emerge info output:

Portage 2.0.51.19 (default-linux/amd64/2004.3, gcc-3.4.3, glibc-2.3.4.20041102-r1, 2.6.11-gentoo-r6 x86_64)
=================================================================
System uname: 2.6.11-gentoo-r6 x86_64 AMD Athlon(tm) 64 Processor 3200+
Gentoo Base System version 1.4.16
Python:              dev-lang/python-2.3.4-r1 [2.3.4 (#1, Feb  7 2005, 11:44:12)]
dev-lang/python:     2.3.4-r1
sys-devel/autoconf:  2.13, 2.59-r6
sys-devel/automake:  1.5, 1.8.5-r3, 1.7.9-r1, 1.6.3, 1.9.4, 1.4_p6
sys-devel/binutils:  2.15.92.0.2-r7
sys-devel/libtool:   1.5.14
virtual/os-headers:  2.6.8.1-r4
ACCEPT_KEYWORDS="amd64"
AUTOCLEAN="yes"
CFLAGS="-O2"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config
/usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O2"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs autoconfig ccache distlocks sandbox strict"
GENTOO_MIRRORS="http://gentoo.nedlinux.nl http://ftp.easynet.nl/mirror/gentoo/ http://gentoo.mirror.sdv.fr http://gentoo.math.bme.hu"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="amd64 X acpi alsa arts berkdb bitmap-fonts bonobo cdr crypt curl doc dvd dvdr esd fam flac font-server fortran gd gdbm gif gnome gpm gstreamer gtk gtkhtml
guile imagemagick imlib ipv6 java jp2 jpeg junit kde ldap libwww lm-sensors lzw
lzw-tiff mad mikmod motif mozilla mp3 mysql ncurses nls ogg opengl oss pam pda pdflib perl png postgres python qt readline ruby samba sdl slang speex ssl tcltk
tcpd tetex tiff truetype truetype-fonts type1-fonts usb userlocales vorbis xml xml2 xmms xpm xrandr xv zlib"
Unset:  ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
 
Portage 2.0.51.19 (default-linux/amd64/2004.3, gcc-3.4.3, glibc-2.3.4.20041102-r1, 2.6.11-gentoo-r6 x86_64)
=================================================================
System uname: 2.6.11-gentoo-r6 x86_64 AMD Athlon(tm) 64 Processor 3200+
Gentoo Base System version 1.4.16
Python:              dev-lang/python-2.3.4-r1 [2.3.4 (#1, Feb  7 2005, 11:44:12)]
dev-lang/python:     2.3.4-r1
sys-devel/autoconf:  2.13, 2.59-r6
sys-devel/automake:  1.5, 1.8.5-r3, 1.7.9-r1, 1.6.3, 1.9.4, 1.4_p6
sys-devel/binutils:  2.15.92.0.2-r7
sys-devel/libtool:   1.5.14
virtual/os-headers:  2.6.8.1-r4
ACCEPT_KEYWORDS="amd64"
AUTOCLEAN="yes"
CFLAGS="-O2"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config
/usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O2"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs autoconfig ccache distlocks sandbox strict"
GENTOO_MIRRORS="http://gentoo.nedlinux.nl http://ftp.easynet.nl/mirror/gentoo/ http://gentoo.mirror.sdv.fr http://gentoo.math.bme.hu"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="amd64 X acpi alsa arts berkdb bitmap-fonts bonobo cdr crypt curl doc dvd dvdr esd fam flac font-server fortran gd gdbm gif gnome gpm gstreamer gtk gtkhtml
guile imagemagick imlib ipv6 java jp2 jpeg junit kde ldap libwww lm-sensors lzw
lzw-tiff mad mikmod motif mozilla mp3 mysql ncurses nls ogg opengl oss pam pda pdflib perl png postgres python qt readline ruby samba sdl slang speex ssl tcltk
tcpd tetex tiff truetype truetype-fonts type1-fonts usb userlocales vorbis xml xml2 xmms xpm xrandr xv zlib"
Unset:  ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS

Created an attachment (id=57438) [edit]
Fixes compilation issue

Could you please try the attached patch? I don't know that package so I can
hardly figure whether this breaks it. 

Yes, it fixes the compilation issue and a quick test of the resulting
executables shows no breakage.
Thanks!

There's a deeper issue here.  On x86, glibc defines uint64_t as unsigned long
long, while on amd64, it's defined as unsigned long.  However, the kernel
defines it as unsigned long long in both cases.  This makes the definitions
different on amd64.

Now, sleuthkit shouldn't need to include <linux/types.h>, but this wouldn't be
a problem if the two definitions were the same.  Likely either the
linux-headers or glibc should be patched.

Yes, on the AMD64 architecture glibc and Linux use different definitions for
the 64 bit integer types. I think that it makes sense for sleuthkit to include
<linux/types.h> as sleuthkit needs low level access to the file system
structures as laid out on the harddisk (or disk image). It should be possible
for system utilities to include both standard and kernel header files.
In my opinion the Linux guys are to blame for using names that are reserved for
compiler and library writers. Their conflicting definition paints us in a
corner. Commenting out the <linux/types.h> include is getting us out of trouble
now; the real soltion would be an attitude adjustment for the kernel hackers.

"On x86, glibc defines uint64_t as unsigned long long, while on amd64, it's
defined as unsigned long."

Which makes sense. You want 64bits unsigned, so you have to do it this way. 
I actually have _no_ idea why the kernel defines it as unsigned long long. In
userspace this results in a 128bit integer type (right?). If that's the case in
kernel-space, then the name uint64_t is indeed surprising.

Why blame the kernel-devs? You actually shouldn't mix kernel and user-space
types - it can mess things badly. In this case, taking the kerne-definitions
makes sense (but I agree a different name would make it simpler)

No, long long is always 64-bit on gcc.

I've added the patch to cvs. Thanks for reporting