CFLAGS="$CFLAGS $CPPFLAGS"
unset CPPFLAGS
and
CPPFLAGS="$CPPFLAGS -O2"
Not sure which is best though...
]]>CPPFLAGS="-D_FORTIFY_SOURCE=2"
I can fix the package build by unsetting CPPFLAGS in the PKGBUILD's build() function.
build() {
cd $srcdir/$pkgname-$pkgver
unset CPPFLAGS
./configure --with-installroot=${pkgdir} \
--mandir=/usr/share/man --homedir=/opt/dcc \
--bindir=/usr/bin --libexecdir=/usr/lib/dcc
make
}
Before I upload an amended package, I'd like to clarify whether fixing it in this way is the right thing to do.
Or, is this a problem with makepkg (I've seen a few similar mentions, like this one). Or is it the fault of something else... gcc, perhaps ?
I'd appreciate advice on how to approach this one.
(I also asked the DCC people about this via their mailing list and the response I got is below.)
The package build tool on Archlinux uses the CPP flag:
CPPFLAGS="-D_FORTIFY_SOURCE=2"
by default. Commenting this line out
in /etc/makepkg.conf results in a successful build using the makepkg
tool. (For the record, FORTIFY_SOURCE=1 fails as well).
From what I can tell, during configure the conflict in sa_family_t
definitions causes the test to fail when using the FORTIFY_SOURCE flag,
making configure believe that the system has no definition of
sa_family_t (or any other INET related definitions).
--
]]>