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