Re: optional -fstack-protector

From: Rasmus Villemoes <>
Date: Fri, 6 Oct 2017 13:19:15 +0200

On 2017-10-05 17:29, Laurent Bercot wrote:
>> Hm, that is a problem indeed. The goal is always for the user CFLAGS to
>> override the automatic CFLAGS. I'm going to fix that.
> Actually, things are working as intended. The contents of the CPPFLAGS,
> CFLAGS and LDFLAGS *environment variables* do not override the defaults
> in the Makefile. However, when CPPFLAGS/CFLAGS/LDFLAGS is used as a
> *make variable* ("make CFLAGS=-fstack-protector=yes"), then it does
> override the defaults.
> If you want the environment variables to also override the defaults,
> you can run "make -e".
> I should still modify the Makefile to make it easier to override
> CFLAGS and friends without having to manually redefine the -I and -L
> paths.

Yes, I obviously don't want to replace CFLAGS or CPPFLAGS whole-sale, as
there might actually be necessary options in there, and I certainly
don't want to pick those out and have to provide them manually.

I just thought that the way you meant for people to add to CFLAGS was by
having those set in the environment at _configure_ time, since you very
explicitly initialize CFLAGS_AUTO to $CFLAGS in the configure scripts.
The problem is then that all the configure logic appends to that
variable, and at the end sets the CFLAGS make variable to $CFLAGS_AUTO.
So maybe a simpler fix is to just do


but that won't catch bad user-supplied cflags at configure time, though.

Dunno, it's up to you, but I'd really like some way to pass _additional_
CFLAGS that are guaranteed to have precedence; I don't care much whether
I have to do it at configure or make time, or whether I need to set a
make or environment variable.

Rasmus Villemoes
Software Developer
Prevas A/S
Hedeager 3
DK-8200 Aarhus N
+45 51210274
Received on Fri Oct 06 2017 - 11:19:15 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:38:49 UTC