Bug 87580 - unionfs-1.0.11 (and 1.0.10) fails to compile with 'F_SETLK64 not found'
Bug#: 87580 Product:  Gentoo Linux Version: unspecified Platform: AMD64
OS/Version: Linux Status: RESOLVED Severity: normal Priority: P2
Resolution: FIXED Assigned To: amd64@gentoo.org Reported By: rgbtxus@myrealbox.com
Component: Core system
URL: 
Summary: unionfs-1.0.11 (and 1.0.10) fails to compile with 'F_SETLK64 not found'
Keywords:  
Status Whiteboard: 
Opened: 2005-04-01 09:42 0000
Description:   Opened: 2005-04-01 09:42 0000
running 2.6.11-gentoo-r3
emerge of union-1.0.9 works fine
emerge =sys-fs/union-1.0.11 fails with error: `F_SETLK64' undeclared
When trying the make by hand I get:  
make -C /lib/modules/2.6.11-gentoo-r3/build SUBDIRS=/root/test/unionfs-1.0.11 FISTDEVMK=/root/test/unionfs-1.0.11/fistdev.mk modules
make[1]: Entering directory `/usr/src/linux-2.6.11-gentoo-r3'
  CC [M]  /root/test/unionfs-1.0.11/locks.o
/root/test/unionfs-1.0.11/locks.c: In function `unionfs_setlk':
/root/test/unionfs-1.0.11/locks.c:143: error: `F_SETLK64' undeclared (first use in this function)


Reproducible: Always
Steps to Reproduce:
1.emerge =sys-fs/union-1.0.11
2.
3.

------- Comment #1 From Stefan Schweizer 2005-04-01 22:15:14 0000 -------
works fine here ..
Are you on the amd64?
Can you please post your full emerge info?

------- Comment #2 From Richard Bratt 2005-04-01 22:33:57 0000 -------
ok, here is my ifo -- and yes, this is an AMD64 system

thor unionfs-1.0.11 # emerge info
Portage 2.0.51.19 (default-linux/amd64/2004.3, gcc-3.4.3, glibc-2.3.4.20041102-r1, 2.6.11-gentoo-r3 x86_64)
=================================================================
System uname: 2.6.11-gentoo-r3 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 19 2005, 23:35:33)]
ccache version 2.3 [enabled]
dev-lang/python:     2.3.4-r1
sys-devel/autoconf:  2.59-r6, 2.13
sys-devel/automake:  1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.4
sys-devel/binutils:  2.15.92.0.2-r1
sys-devel/libtool:   1.5.10-r4
virtual/os-headers:  2.6.8.1-r4
ACCEPT_KEYWORDS="amd64"
AUTOCLEAN="yes"
CFLAGS="-march=k8 -O2 -pipe -fomit-frame-pointer"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/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/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="-march=k8 -O2 -pipe -fomit-frame-pointer"
DISTDIR="/fs/source/distfiles"
FEATURES="autoaddcvs autoconfig buildpkg ccache distcc distlocks sandbox userpriv"
GENTOO_MIRRORS="ftp:///ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://open-systems.ufl.edu/mirrors/gentoo http://mirror.datapipe.net/gentoo http://mirror.datapipe.net/gentoo"
LANG="en_US"
MAKEOPTS="-j2"
PKGDIR="/fs/packages/amd64"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/fs/source/usr-portage"
PORTDIR_OVERLAY="/fs/source/portage-overlay"
SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage"
USE="amd64 2 a52 aac dga divx4linux doc dv dvd dvdr dvdread emacs ex exif faad fbcon ffmpeg freetype ftp gimp gimpprint ginac glade gnuplot gs imap java javascript jikes matroska mbox mng moznomail mpeg4 mplayer ocaml offensive ogg pcre plotutils quotes sasl sox spell theora transcode type1 xine xvid"
Unset:  ASFLAGS, CBUILD, CTARGET, LC_ALL, LDFLAGS

------- Comment #3 From Stefan Schweizer 2005-04-01 23:00:13 0000 -------
sorry, I have no experience in amd64-porting, since I dont own one. However I
would be happy to add a patch, when you find,hack up or already have one.

------- Comment #4 From Malcolm Lashley (RETIRED) 2005-05-08 18:19:21 0000 -------
I fixed this a while ago on 64bit Xeon (Nocona) but forgot to commit the
patch... 2 files forget to include compat.h and thus FSETLK64 is undefined -
since the default FSETLK is 64bit wide on our arch. Tested again on my amd64,
and though I am quite sure the patch won't break 32bit - I leave it to the
maintainer to apply unconditionally.

InCVS, cheers.