You are not logged in.
I have a pkg in the AUR, dcc, which fails to build with the current GCC toolchain (4.8.2.8). It does, however, build on a system with GCC 4.6.3. The problem has been identified as being caused by the FORTIFY_SOURCE=2 option in /etc/makepkg.conf.
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).
--
Last edited by starfry (2014-06-15 08:59:58)
Offline
Offline
I read that one, there's a couple of suggestions there and it's where I got the idea described above from. Other solutions that could be used include
CFLAGS="$CFLAGS $CPPFLAGS"
unset CPPFLAGS
and
CPPFLAGS="$CPPFLAGS -O2"
Not sure which is best though...
Offline
I went with the latter. Package updated.
Offline