This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 09/12] Link various tests with -fno-stack-protector.
- From: Florian Weimer <fweimer at redhat dot com>
- To: Nix <nix at esperi dot org dot uk>, libc-alpha at sourceware dot org
- Cc: Nick Alcock <nick dot alcock at oracle dot com>
- Date: Thu, 15 Dec 2016 15:43:52 +0100
- Subject: Re: [PATCH 09/12] Link various tests with -fno-stack-protector.
- Authentication-results: sourceware.org; auth=none
- References: <20161128123228.30856-1-nix@esperi.org.uk> <20161128123228.30856-10-nix@esperi.org.uk>
On 11/28/2016 01:32 PM, Nix wrote:
diff --git a/elf/Makefile b/elf/Makefile
index daf0ebd..7588ca0 100644
--- a/elf/Makefile
+++ b/elf/Makefile
@@ -775,6 +775,10 @@ $(objpfx)filtmod1.so: $(objpfx)filtmod1.os $(objpfx)filtmod2.so
$< -Wl,-F,$(objpfx)filtmod2.so
$(objpfx)filter: $(objpfx)filtmod1.so
+# These do not link against libc.
+CFLAGS-filtmod1.c = $(no-stack-protector)
+CFLAGS-filtmod2.c = $(no-stack-protector)
Is this really necessary for filtmod2.c?
diff --git a/stdlib/Makefile b/stdlib/Makefile
index 3cce9d9..6d7586e 100644
--- a/stdlib/Makefile
+++ b/stdlib/Makefile
@@ -187,6 +187,9 @@ LDFLAGS-tst-putenv = $(no-as-needed)
$(objpfx)tst-putenvmod.so: $(objpfx)tst-putenvmod.os $(link-libc-deps)
$(build-module)
+# This is not only not in libc, it's not even linked with it.
+CFLAGS-tst-putenvmod.c += $(no-stack-protector)
I think this papers over an actual failure. Based on my build logs,
tst-putenvmod.so is properly linked against libc (including
libc_nonshared.a).
diff --git a/sysdeps/x86_64/Makefile b/sysdeps/x86_64/Makefile
index 6d99284..fbe138f 100644
--- a/sysdeps/x86_64/Makefile
+++ b/sysdeps/x86_64/Makefile
@@ -46,6 +46,9 @@ tests-pie += $(quad-pie-test)
test-extras += tst-quadmod1pie tst-quadmod2pie
extra-test-objs += tst-quadmod1pie.o tst-quadmod2pie.o
+CFLAGS-tst-quad1pie.c = $(no-stack-protector)
+CFLAGS-tst-quad2pie.c = $(no-stack-protector)
This looks like a genuine test failure as well. I'll try to reproduce
it, after I have tracked down the more catastrophic MIPS build failure …
Thanks,
Florian