Cannot compile with gcc 4.8

Sven Willenberger sven@dmv.com
Fri Jun 13 16:43:25 UTC 2014


On Fri, 13 Jun 2014 15:58:36 GMT
Vernon Schryver <vjs@rhyolite.com> wrote:

> > 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?
> 
Here are two outputs (btw, it's not just sa_family_t that's affected,
that is just the first one that is encountered during compiling at
which point it bails):

$ ./configure 
checking for AF_LOCAL... yes
checking for AF_INET6... yes
checking for socklen_t... yes
checking for in_addr_t... yes
checking for sa_family_t... yes
checking for in_port_t... yes
checking for sa_len... no
checking for sin6_scope_id... yes

$ env CPPFLAGS="-D_FORTIFY_SOURCE=2" ./configure
checking for AF_LOCAL... no
checking for AF_INET6... no
checking for socklen_t... no
checking for in_addr_t... no
checking for sa_family_t... no
checking for in_port_t... no
checking for sa_len... no
checking for sin6_scope_id... no


These are not the only variables affected, there are several that
differ depending on the presence of FORTIFY. (Running a diff on the
sorted outputs of ./configure with and without the flag is revealing).

Agreed on just undefining FORTIFY_SOURCE for this particular build
rather than as a global setting, just wanted a quick and dirty package
build to test.

-- 
Sven Willenberger
Delmarva Online

key:    http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xCAB7246B
key-id: 0xCAB7246B

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://www.rhyolite.com/pipermail/dcc/attachments/20140613/8e7b200f/attachment.bin>


More information about the DCC mailing list

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