90489 2005-04-26 05:57 0000 sleuthkit-2.01 doesn't compile on AMD64 2005-04-28 12:48:30 0000 1 1 1 Unclassified Gentoo Linux Applications unspecified AMD64 All RESOLVED FIXED InCVS P2 normal --- 1 mathfox@xs4all.nl amd64@gentoo.org mathfox@xs4all.nl 2005-04-26 05:57:39 0000 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 config@gentoo.org 2005-04-27 14:21:18 0000 Created an attachment (id=57438) 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. mathfox@xs4all.nl 2005-04-27 16:25:30 0000 Yes, it fixes the compilation issue and a quick test of the resulting executables shows no breakage. Thanks! dang@gentoo.org 2005-04-27 19:58:51 0000 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. mathfox@xs4all.nl 2005-04-27 23:58:19 0000 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. config@gentoo.org 2005-04-28 00:32:41 0000 "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) dang@gentoo.org 2005-04-28 07:34:06 0000 No, long long is always 64-bit on gcc. config@gentoo.org 2005-04-28 12:48:30 0000 I've added the patch to cvs. Thanks for reporting 57438 2005-04-27 14:21 0000 Fixes compilation issue sleuthkit.patch text/plain LS0tIHNyYy9taXNjL3Rza19vcy5oLm9sZAkyMDA1LTA0LTI4IDIzOjEyOjU2LjAwMDAwMDAwMCAr MDAwMAorKysgc3JjL21pc2MvdHNrX29zLmgJMjAwNS0wNC0yOCAyMzoxMTozNC4wMDAwMDAwMDAg KzAwMDAKQEAgLTc3LDcgKzc3LDcgQEAKICAgKi8KICNpZiBkZWZpbmVkKExJTlVYMikKICNkZWZp bmUgU1VQUE9SVEVECi0jaW5jbHVkZSA8bGludXgvdHlwZXMuaD4KKy8qICNpbmNsdWRlIDxsaW51 eC90eXBlcy5oPiAqLyAKICNpbmNsdWRlIDxpbnR0eXBlcy5oPgogI2VuZGlmCQkJCS8qIExJTlVY ICovCiAK