From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 2206) id 2DD563858D39; Mon, 27 Mar 2023 13:13:34 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2DD563858D39 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1679922814; bh=yqJTNoQCG0+Unch7/O82HRJdQIMCoMpMT8T+vWhoVUw=; h=From:To:Subject:Date:From; b=m3jXBGLEbNA8HsmRYfPvLlG79TgcAKUjH5x1HOXxozE2K0SbWKXi1Z+ihNfAfKG3G PE7YAOkq78prBOztGDHVYYw1iIcXI4KVCkaSb/01k/WcGucRsE6zXxypXfx69aHQpx DxhH5rlVHawBKd4n2hfGM+nW4ihGJ1yBwcKhI1bE= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Siddhesh Poyarekar To: glibc-cvs@sourceware.org Subject: [glibc] stdio-common: tests: don't double-define _FORTIFY_SOURCE X-Act-Checkin: glibc X-Git-Author: Sam James X-Git-Refname: refs/heads/master X-Git-Oldrev: 952b7630c72ae245f370f1a2bcaade82bb1f7361 X-Git-Newrev: ecf8ae6704d5034fc2d5e29e5dc88dbca981581e Message-Id: <20230327131334.2DD563858D39@sourceware.org> Date: Mon, 27 Mar 2023 13:13:34 +0000 (GMT) List-Id: https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=ecf8ae6704d5034fc2d5e29e5dc88dbca981581e commit ecf8ae6704d5034fc2d5e29e5dc88dbca981581e Author: Sam James Date: Tue Feb 21 09:27:26 2023 +0000 stdio-common: tests: don't double-define _FORTIFY_SOURCE Exactly the same as 35bcb08eaa953c9b8bef6ab2486dc4361e1f26c0. If using -D_FORITFY_SOURCE=3 (in my case, I've patched GCC to add =3 instead of =2 (we've done =2 for years in Gentoo)), building glibc tests will fail on tst-bz11319-fortify2 like: ``` : error: "_FORTIFY_SOURCE" redefined [-Werror] : note: this is the location of the previous definition cc1: all warnings being treated as errors ``` It's just because we're always setting -D_FORTIFY_SOURCE=2 rather than unsetting it first. If F_S is already 2, it's harmless, but if it's another value (say, 1, or 3), the compiler will bawk. (I'm not aware of a reason this couldn't be tested with =3, but the toolchain support is limited for that (too new), and we want to run the tests everywhere possible.) As Siddhesh noted previously, we could implement some fallback logic to determine the maximal F_S value supported by the toolchain, which is a bit easier now that autoconf-archive has been updated for F_S=3 (https://github.com/autoconf-archive/autoconf-archive/pull/269), but let's revisit this if it continues to crop up. Signed-off-by: Sam James Reviewed-by: Siddhesh Poyarekar Diff: --- stdio-common/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/stdio-common/Makefile b/stdio-common/Makefile index a14ee487ea..7cf8d814ea 100644 --- a/stdio-common/Makefile +++ b/stdio-common/Makefile @@ -450,7 +450,7 @@ CFLAGS-tst-gets.c += -Wno-deprecated-declarations # BZ #11319 was first fixed for regular vdprintf, then reopened because # the fortified version had the same bug. -CFLAGS-tst-bz11319-fortify2.c += -D_FORTIFY_SOURCE=2 +CFLAGS-tst-bz11319-fortify2.c += -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 CFLAGS-tst-memstream-string.c += -fno-builtin-fprintf