From owner-freebsd-ports@FreeBSD.ORG Tue Apr 27 21:26:15 2004 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0DBFF16A4CE for ; Tue, 27 Apr 2004 21:26:15 -0700 (PDT) Received: from usgrant.trismegistus.net (wbar11.dal1-4-12-223-109.dsl-verizon.net [4.12.223.109]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4045143D5C for ; Tue, 27 Apr 2004 21:26:14 -0700 (PDT) (envelope-from hermes@trismegistus.net) Received: from sherman (sherman.trismegistus.net [192.168.0.12]) by usgrant.trismegistus.net (Postfix) with ESMTP id 7E09A7DF; Tue, 27 Apr 2004 22:22:20 -0500 (CDT) Date: Tue, 27 Apr 2004 22:22:20 -0500 (CDT) From: Hermes Trismegistus To: Michael Edenfield In-Reply-To: <20040426221217.GA40770@wombat.localnet> Message-ID: <20040427220951.E31761@sherman.trismegistus.net> References: <20040426221217.GA40770@wombat.localnet> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: ports@freebsd.org Subject: Re: The ongoing saga of lsof-4.71.1 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2004 04:26:15 -0000 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 > > #if FREEBSDV>=520 > /* > * In FreeBSD >= 5.2 the cpumask_t typedef is only made in if > * _KERNEL is predefined. However, predefining _KERNEL before #include'ing > * causes redefinition errors for boolean_t and vm_page_t when > * is #include'd with _KERNEL predefined. Since lsof must have > * _KERNEL predefined when 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 > >