The ongoing saga of lsof-4.71.1
hermes at trismegistus.net
Tue Apr 27 21:26:15 PDT 2004
Mike, one hell of a job at some really good sleuthing. I lacked your
persistence, or maybe your curiosity. I had given up on the newer version
of lsof after spending about half the time you spent. I just figured what
the fuck, I'll stay with the older but working version. I guess you and I
are the only ones without the "__cpumask_t" value set to some typedef.
Where did you comment it out (what file)?
J. Craig Woods
UNIX/Linux Network/System Administration
Entropy requires no maintenance.
On Mon, 26 Apr 2004, Michael Edenfield wrote:
> I am one of the people having problems building lsof's latest release on
> -CURRENT and have spent a few hours trying to figure out why. I managed
> to get the program to build but I can't figure out what went wrong in
> the first place, or more specifically, why *everyone* isn't having this
> My ports tree was cvsup's immediately before I began. I also deleted
> /usr/includes and did a `make buildincludes; make installincludes` in
> /usr/src before beginning.
> The error, as usual, was in machine.h in the lsof work directory. This
> is a symlink to dialiects/freebsd/machine.h and contains the following
> #include <sys/types.h>
> #if FREEBSDV>=520
> * In FreeBSD >= 5.2 the cpumask_t typedef is only made in <sys/types.h> if
> * _KERNEL is predefined. However, predefining _KERNEL before #include'ing
> * <sys/types.h> causes redefinition errors for boolean_t and vm_page_t when
> * <vm/vm.h> is #include'd with _KERNEL predefined. Since lsof must have
> * _KERNEL predefined when <vm/vm.h> is #include'd, the expedient choice has
> * been made to do the cpumask_t typedef here.
> typedef __cpumask_t cpumask_t;
> #endif /* FREEBSDV>=520 */
> The build error is complaining that __cpumask_t has no storage class or
> size, so it obviously can't use it in a typedef. So I went looking for
> __cpumask_t on my system and came up empty. It's never defined
> anywhere, neither in the system headers nor or the lsof source itself.
> The only place it appears is in machine.h where it's used as the source
> of a typedef.
> root at basement:/usr/ports/sysutils/lsof/work/lsof_4.72A.freebsd$ find / -name "*.h" | xargs grep "__cpumask_t"
> /usr/ports/sysutils/lsof/work/lsof_4.72A.freebsd/dialects/freebsd/machine.h:typedef __cpumask_t cpumask_t;
> /usr/ports/sysutils/lsof/work/lsof_4.72A.freebsd/machine.h:typedef __cpumask_t cpumask_t;
> root at basement:/usr/ports/sysutils/lsof/work/lsof_4.72A.freebsd$
> My next step was to look for the system's definition of cpumask_t, with
> the intent to ''fix'' machine.h. But I also can't find that type defined
> anywhere. The funny thing is, cpumask_t isn't actually *used* in the lsof
> source tree. I commented out the typedef and now everything builds
> fine. So my question is now, where *should* __cpumask_t and/or cpumask_t get
> defined, why don't I have those definitions, and why does everyone else
> seem to have them?
More information about the freebsd-ports