Am Mon, 08 Apr 2013 09:18:40 +0200 schrieb Thomas Bächler <thomas@archlinux.org>:
Am 08.04.2013 08:54, schrieb Allan McRae:
What do we do? Do we need to ignore the fact the this should be in CPPFLAGS and move it back to C{,XX}FLAGS?
The other options is for packages that are affected by this to unset the CPPFLAGS and add it to CFLAGS in the PKGBUILD, but I have no idea how many packages this affects. What portion of KDE and GNOME were built with pacman-4.1?
In PKGBUILD:
CPPFLAGS="$CPPFLAGS -O2" - problem solved.
"man feature_test_macros" says: _FORTIFY_SOURCE (since glibc 2.3.4) Defining this macro causes some lightweight checks to be performed to detect some buffer overflow errors when employing various string and memory manipulation functions. Not all buffer overflows are detected, just some common cases. In the current implementation checks are added for calls to memcpy(3), mempcpy(3), memmove(3), memset(3), stpcpy(3), strcpy(3), strncpy(3), strcat(3), strncat(3), sprintf(3), snprintf(3), vsprintf(3), vsnprintf(3), and gets(3). If _FORTIFY_SOURCE is set to 1, with compiler optimization level 1 (gcc -O1) and above, checks that shouldn't change the behavior of conforming programs are performed. With _FORTIFY_SOURCE set to 2 some more checking is added, but some conforming programs might fail. Some of the checks can be performed at compile time, and result in compiler warnings; other checks take place at run time, and result in a run-time error if the check fails. Use of this macro requires compiler support, available with gcc(1) since version 4.0. I'm for "unset CPPFLAGS" in our PKGBUILD and reporting it upstream. Any other solution is probably not worth the effort. I don't see any advantage to move it back to CFLAGS for certain packages. Maybe Thomas' workaround is also a valid solution until upstream ships proper fixes. -Andy