Date: Tue, 27 Apr 2004 22:22:20 -0500 (CDT) From: Hermes Trismegistus <hermes@trismegistus.net> To: Michael Edenfield <kutulu@kutulu.org> Cc: ports@freebsd.org Subject: Re: The ongoing saga of lsof-4.71.1 Message-ID: <20040427220951.E31761@sherman.trismegistus.net> In-Reply-To: <20040426221217.GA40770@wombat.localnet> References: <20040426221217.GA40770@wombat.localnet>
next in thread | previous in thread | raw e-mail | index | archive | help
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)? Thanks, J. Craig Woods UNIX/Linux Network/System Administration http://www.trismegistus.net/resume.htm 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@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@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 > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040427220951.E31761>