public inbox for glibc-cvs@sourceware.org
help / color / mirror / Atom feed
From: Sam James <sjames@sourceware.org>
To: glibc-cvs@sourceware.org
Subject: [glibc/release/2.37/master] stdio-common: tests: don't double-define _FORTIFY_SOURCE
Date: Tue, 11 Apr 2023 02:37:08 +0000 (GMT)	[thread overview]
Message-ID: <20230411023708.316BF3858D28@sourceware.org> (raw)

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=1d63573f81945a489ea169636fa11850bc74716b

commit 1d63573f81945a489ea169636fa11850bc74716b
Author: Sam James <sam@gentoo.org>
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:
    ```
    <command-line>: error: "_FORTIFY_SOURCE" redefined [-Werror]
    <built-in>: 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 <sam@gentoo.org>
    Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
    (cherry picked from commit ecf8ae6704d5034fc2d5e29e5dc88dbca981581e)

Diff:
---
 stdio-common/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/stdio-common/Makefile b/stdio-common/Makefile
index 652d9e5f95..fdc49f32ea 100644
--- a/stdio-common/Makefile
+++ b/stdio-common/Makefile
@@ -433,7 +433,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

                 reply	other threads:[~2023-04-11  2:37 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230411023708.316BF3858D28@sourceware.org \
    --to=sjames@sourceware.org \
    --cc=glibc-cvs@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).