ports/47061: Conflicting system headers by build of graphics/cqcam

Mark Linimon linimon at lonesome.com
Tue Dec 23 20:30:24 PST 2003


The following reply was made to PR ports/47061; it has been noted by GNATS.

From: Mark Linimon <linimon at lonesome.com>
To: freebsd-gnats-submit at FreeBSD.org, bvgastel at bitpowder.com
Cc:  
Subject: Re: ports/47061: Conflicting system headers by build of graphics/cqcam
Date: Tue, 23 Dec 2003 22:24:20 -0600

 This is really a kernel problem.  I am going to go ahead and commit a
 workaround for this and the one or two other ports with this problem --
 but the workaround is basically unacceptable.
 
 The underlying problem is that machine/cpufunc.h for i386 has had
 a definition for a machine function 'ffs' for, oh, say, about 9 years
 now.  However, man ffs will show you that there is an ffs(3) function
 as well.  Even after reading the source it's not clear to me if these
 are supposed to have the same purpose -- someone with a more intimate
 knowledge of i386 arch is going to have to rule for certain.
 
 Back in 2002 a commit was done to create 'strings.h' to provide
 better adherance to POSIX.  When this was done, a prototype for
 ffs() was introduced for ffs(3).  These prototypes fight with each
 other.  From user code, there appears to be no way (to me) to
 allow access to both.  However, this port, among others, wishes
 to use the strings.h definitions _and_ the inb() and outb()
 functions which only cpufunc.h provides.
 
 The only way to (correctly) fix this has to do with changes to
 the include files, and that's outside the charter of the ports folks.
 
 In the meantime, I'm going to hold my nose and commit an include
 file to the port that is merely the inb/outb functions.  This is
 clearly a hack that should go away once a "correct" solution is found.
 
 mcl
 


More information about the freebsd-bugs mailing list