[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

lsof on Debian FreeBSD



tag 589103 +help
thanks

I have been looking at what it will take to build lsof on kfreebsd.
Obviously the first step is passing '-n freebsd' to './Configure' as noted
earlier on the bug report. You can see the current state of our work at

Vcs-Git: git://git.debian.org/git/collab-maint/lsof.git
Vcs-Browser: http://git.debian.org/?p=collab-maint/lsof.git

However once that is done one hits the problem described in section 8.6 of the FAQ:

> 8.6	Why can't Configure create lsof_owner.h for FreeBSD 6 and above?
>
> 	Lsof may report:
>
> 	    Creating ./lockf_owner.h from /usr/src/sys/kern/kern_lockf.c
> 	    FATAL ERROR: can't read /usr/src/sys/kern/kern_lockf.c
> 	    FATAL ERROR: ./lockf_owner.h creation failed (see 00FAQ)
> 	or
> 	    Creating ./lockf_owner.h from /usr/src/sys/kern/kern_lockf.c
> 	    FATAL ERROR: ./lockf_owner.h creation failed (see 00FAQ)
>
> 	Those messages mean that lsof's Configure script failed to
> 	create a local header file, ./lockf_owner.h, needed to use the
> 	new kernel file locking code of some versions of FreeBSD 6 and
> 	above.
>
> 	The changes that implement that new locking code alter the
> 	lockf structure in <sys/lockf.h> and introduce a new structure,
> 	lockf_entry, to that header file.  When Configure detects the
> 	presence of the lockf_entry definition in <sys/lockf.h>, it
> 	tries to construct the local header file, ./lockf_owner.h.
>
> 	Configure has to do that  because an unfortunate side effect of
> 	the new kernel file locking code is that <sys/lockf.h> doesn't
> 	contain the lockf_owner structure definition referenced in its
> 	own lockf structure.  Lsof needs to access elements of that
> 	lockf_owner structure to determine if a lock belongs to the
> 	process that has a file open.
>
> 	The missing lockf_owner structure definition is in the kernel
> 	source file, typically /usr/src/sys/kern/kern_lockf.c.
> 	Configure tries to extract the lockf_owner structure definition
> 	from kern_lockf.c into lsof's local header file, ./lockf_owner.h.
> 	If Configure can't do that, it reports:
>
> 	    FATAL ERROR: ./lockf_owner.h creation failed
>
> 	If Configure can't even read kern_lockf.c, it first reports:
>
> 	    FATAL ERROR: can't read /usr/src/sys/kern/kern_lockf.c
>
> 	The work-around for this problem is to update the FreeBSD
> 	kernel /usr/src tree (e.g., do a CVSup or csup) on the system
> 	where lsof is to be built and then do a "make buildworld"
> 	followed by a "make installworld".
>

So the problem is to translate this into "Debian-speak". I think I see how
to do this in principle but some of the details elude me.

1.) Declare a build dependency: kfreebsd-source[kfreebsd-any]
2.) Have a clause in the override_dh_auto_configure rule that checks for
the kfreebsd OS and copies the compressed tarball to somewhere in the build
space; uncompresses and untars it; and sets the FREEBSD_SYS environment
variable accordingly.
3.) The kfreebsd-source copies will need to be cleaned up as part of the clean
rule.

The bit  that I am most unclear about is how to tie up the Debian version
for lsof, the kernerl version and how to pick the correct version of
kfreebsd-source from the virtual package. I suppose one way to go is
to make "lsof" a virtual package depending on
"lsof-linux | lsof-kfreebsd | lsof-hurd". lsof-kfreebsd would itself
be a virtual package depending on the real package "lsof-kfreebsd-OSVER".

Can one evade the whole issue by forcing lsof on to use /proc? Maybe
we should take that approach but discuss with upstream.


Reply to: