The ongoing saga of lsof-4.71.1

Hermes Trismegistus hermes at
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
> problem.
> 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
> code:
> #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?
> --Mike

More information about the freebsd-ports mailing list