Cannot compile with gcc 4.8

Vernon Schryver vjs@rhyolite.com
Fri Jun 13 15:58:36 UTC 2014


> From: Sven Willenberger <sven@dmv.com>
> To: Vernon Schryver <vjs@rhyolite.com>
> Cc: dcc@jelmail.com, dcc@rhyolite.com

> 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).

How is -D_FORTIFY_SOURCE=2 breaking things?

This modified version of the script equivalent to the DCC ./configure
still doesn't fail on that Debian system:

#! /bin/sh
cpp -D_FORTIFY_SOURCE=2 <<EOF | grep sa_family_t
#include <sys/types.h>
#include <netinet/in.h>
#include <sys/socket.h>
#ifdef sa_family_t
 " sa_family_t "
#endif
EOF

https://www.google.com/search?q=FORTIFY_SOURCE+gcc+4.8
found more reports of problems with FORTIFY_SOURCE
including a work-arund of adding -U_FORTIFY_SOURCE to an environment
variable like CFLAGS.  If that works in this case, it might be more
palatable than modifying /etc/makepkg.conf


I'd like to understand what -D_FORTIFY_SOURCE=2 is doing to cpp and
/usr/include to hide sa_family_t and only sa_family_t.  The same kind
of check is used by the DCC ./configure to look for in_addr_t and
in_port_t but it sounds as if the check is working for them.
Is there a new cleverness with #if FORTIFY_SOURCE around sa_family_t
in /usr/include?


thanks,
Vernon Schryver    vjs@rhyolite.com



More information about the DCC mailing list

Contact vjs@rhyolite.com by mail or use the form.