Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#70701 - [gcc] Trying to fix errors due to -Werror=format-security

Attached to Project: Arch Linux
Opened by Joey Dumont (valandil) - Tuesday, 04 May 2021, 01:33 GMT
Last edited by Allan McRae (Allan) - Thursday, 01 July 2021, 01:05 GMT
Task Type Bug Report
Category Packages: Core
Status Assigned
Assigned To Giancarlo Razzolini (grazzolini)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 1
Private No


Description: -Werror=format-security was recently added to the default CFLAGS that makepkg uses when building software, here: This causes errors when trying to build gcc.

In this bug report, I've attached an attempt at a patch (there is patch within a patch to show the changes in the PKGBUILD, hopefully that's legible) that fixes some straightfoward -Werror=format-security errors. However, even with the patch, gcc fails to build later in the build with that error:

make[5]: Entering directory '/build/gcc/src/gcc-build/x86_64-pc-linux-gnu/32/libgcc'
# If this is the top-level multilib, build all the other
# multilibs.
ln -s /build/gcc/src/gcc/libgcc/enable-execute-stack-empty.c enable-execute-stack.c
ln -s /build/gcc/src/gcc/libgcc/unwind-generic.h unwind.h
ln -s /build/gcc/src/gcc/libgcc/config/i386/linux-unwind.h md-unwind-support.h
ln -s /build/gcc/src/gcc/libgcc/config/i386/sfp-machine.h sfp-machine.h
ln -s /build/gcc/src/gcc/libgcc/gthr-posix.h gthr-default.h
DEFINES='' HEADERS='/build/gcc/src/gcc/libgcc/config/i386/elf-lib.h /build/gcc/src/gcc/libgcc/config/i386/value-unwind.h' \
/build/gcc/src/gcc/libgcc/ > tmp-libgcc_tm.h
/bin/sh /build/gcc/src/gcc/libgcc/../move-if-change tmp-libgcc_tm.h libgcc_tm.h
echo timestamp > libgcc_tm.stamp
/build/gcc/src/gcc-build/./gcc/xgcc -B/build/gcc/src/gcc-build/./gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -fno-checking -g -march=x86-64 -mtune=generic -O2 -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2,-D_GLIBCXX_ASSERTIONS -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -m32 -O2 -g -march=x86-64 -mtune=generic -O2 -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2,-D_GLIBCXX_ASSERTIONS -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -DIN_GCC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wno-error=format-diag -Wold-style-definition -isystem ./include -fpic -mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection -mshstk -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fpic -mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection -mshstk -I. -I. -I../../.././gcc -I/build/gcc/src/gcc/libgcc -I/build/gcc/src/gcc/libgcc/. -I/build/gcc/src/gcc/libgcc/../gcc -I/build/gcc/src/gcc/libgcc/../include -I/build/gcc/src/gcc/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c /build/gcc/src/gcc/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS
cc1: error: ‘-Wformat-security’ ignored without ‘-Wformat’ [-Werror=format-security]

The resolution in mips64-elf-gcc (which is not yet published to AUR, but we have a PR in progress here: was to add --enable-build-format-warnings to the configure flags, but somehow it doesn't seem to get passed here. Do you know what controls these flags?

Additional questions:
* do you have additional guidance on how to fix errors related to -Werror=format-security?
* in the process of updating this package to gcc/11.1.0, are you planning on opening a bug report with format-security patches upstream? If not, I can submit one with the patch that applies to the latest version of gcc.

Additional info:
* gcc/10.2.0
* attempted in a clean chroot

Steps to reproduce:
* try to build gcc with the latest makepkg.conf.
This task depends upon

Comment by Eli Schwartz (eschwartz) - Tuesday, 04 May 2021, 01:59 GMT
-Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -DIN_GCC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wno-format

So this build rule here disabled -Wformat explicitly, later on in the command line.
Comment by Eli Schwartz (eschwartz) - Tuesday, 04 May 2021, 02:01 GMT
Since you investigated first and already wrote a patch, why don't you submit it upstream? ;)
Comment by Allan McRae (Allan) - Wednesday, 05 May 2021, 00:34 GMT
Simple workaround, which is somewhat intended by upstream:
Comment by Joey Dumont (valandil) - Wednesday, 05 May 2021, 00:52 GMT
I did add the --enable-build-format-warnings to the configure call, but it just failed later in the build process than without it. I'll test the Fedora patch.
Comment by Allan McRae (Allan) - Wednesday, 05 May 2021, 00:59 GMT
--enable-build-format-warnings adds -Wno-format in areas it is needed. That patch make it add -Wno-format and -Wno-format-security. That will fix the following error you saw:

cc1: error: ‘-Wformat-security’ ignored without ‘-Wformat’ [-Werror=format-security]
Comment by Joey Dumont (valandil) - Wednesday, 05 May 2021, 01:48 GMT
Sorry for the double post, hit the refresh button by accident. I guess I misread the macro, I thought add --enable-build-format-warnings would remove the -Wno-format from LOOSE_WARN, not add it.

--I did add the --enable-build-format-warnings to the configure call, but it just failed later in the build process than without it. I'll test the Fedora patch.
Comment by Joey Dumont (valandil) - Saturday, 08 May 2021, 00:52 GMT
I opened a bug report upstream, and it turns out that just passing "%s" to some messages actually break formatting. In my limited testing I couldn't reproduce, but I'll dig deeper into the files above and report back both here and the upstream bug report:
Comment by Jonathon (jonathon) - Saturday, 08 May 2021, 01:21 GMT
There's a comment on a linked bug

> Martin Liška 2021-04-22 12:30:14 UTC
> You're using a non-default -Wformat-security which is something GCC cannot be built with.

Is this flag just trying to do something that isn't intended to be done while compiling GCC, so the patch already linked by Allan is the correct approach here?
Comment by Joey Dumont (valandil) - Saturday, 08 May 2021, 02:20 GMT
A definite possibility.

In the upstream bug report, I added a second patch, which implements Allan's suggestion for the libgcc errors. The workaround is probably needed for libgcc, as some flags seem to be statically set during the bootstrap of libgcc, and I think Martin's comment applies there.

For the patch attached here, when properly fixed, would actually resolve Wformat-security warnings libcpp.

Given all that, this bug report probably aught to be closed, and progress tracked in the gcc bug report, as it doesn't really affect packaging.

Thanks for your patience!
Comment by Joey Dumont (valandil) - Monday, 21 June 2021, 02:00 GMT
FYI, I cannot build the latest gcc PKGBUILD in ABS in a clean chroot that has the Werror=format-security flags. The current patch only addresses issues in the gcc component, while there are issues in the libcpp component, as well as the gcc/c subcomponent. The first can be fixed by adding the build-format-warnings option to, and add the Wno-error=format-security flag to the warn section of the CFLAGS. In the gcc/c subcomponent, the issue is that source actually take the strict_warn build variable to set its CFLAGS, which by default the --disable-build-format-warnings doesn't touch. I have added -Wno-error=format-security to the strict_warn build variable in my patch, but I don't how more "targeted" this is than just settings CFLAGS and CXXFLAGS to "Wno-error=format-security" in the PKGBUILD.

To build, edit the PKGBUILD to adjust the strip to 1 and add the --disable-build-format-warnings option to the configure call (I'm not sure why it's not the default in gcc/c).
Comment by Daniel Tobias (dant) - Thursday, 04 November 2021, 16:32 GMT
I got past this by just removing those flags, obviously doesn't fix it, but gets around it for now.