[arch-dev-public] Build issues due to -D_FORTIFY_SOURCE=2 in CPPFLAGS
Hi, With pacman-4.1 we introduced CPPFLAGS in makepkg.conf and moved the -D_FORTIFY_SOURCE=2 flag out of C{,XX}FLAGS to there (where it should be). I did a survey of packages and found for most this made no difference to the build. As I mentioned earlier, it even fixes the build of curl which refuses the use of -D flags in CFLAGS. However, there is an issue. The use of _FORTIFY_SOURCE without optimizations omits a warning. This appears to affect software with configure scripts using really old version of autoconf, as this warning output is enough to make the compile think it can not find the C preprocessor. The preprocessor error is fixed in newer versions of autoconf, although it appears that the warning is enough to cause header detection to fail, even with new versions - I am seeing this with gcc/binutils. So we have an issue... This is probably not going to magically fix itself any time soon and other distributions patch FORTIFY_SOURCE into their compiler to only turn on with optimization so will never see this issue. Also, going to the autoconf source would still require all software to update their autotools files as an "autoreconf" will likely have issues requiring old autoconf versions. 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? Allan
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.
On 8 April 2013 15:18, Thomas Bächler
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?
So, as far as I understand, we're supposed to identify this issue from lines like: warning: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Wcpp] (e.g. output from i686 build of unsupported package gcc-gcj) But should there be any case where this warning is not shown? Say, for e.g., if -Wcpp or -Wall is not used? ...
In PKGBUILD:
CPPFLAGS="$CPPFLAGS -O2" - problem solved.
... If not, then we don't really need any kind of conditioning to recognise it. Editing buildscripts to unset CPPFLAGS (or append -O[n] to it) would be fine in that case, but if there are non-intrusive alternatives we should pursue them. Deciding on [n] for O[n] is really not the business of the buildscript, and you'd want to move the affected flag (back) to C{,XX}FLAGS if you don't append. You can do either of them properly, sure, but not as a clean one-liner (you'd have to at least grep [n] from somewhere). -- GPG/PGP ID: C0711BF1
Am Mon, 08 Apr 2013 09:18:40 +0200
schrieb Thomas Bächler
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
On 08/04/13 17:18, Thomas Bächler wrote:
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.
I took a much more restrained approach and only adjusted configure test. e.g.: sed -i "/ac_cpp=/s/\$CPPFLAGS/\$CPPFLAGS -O2/" libiberty/configure Allan
participants (4)
-
Allan McRae
-
Andreas Radke
-
Rashif Ray Rahman
-
Thomas Bächler