Hi, Jeff King wrote: > I wonder if this points to this patch touching the wrong level. These > compiler flags are a thing that _some_ builds want (i.e., production > builds where people care most about security and not about debugging), > but not necessarily all. > > I'd have expected this to be tweakable by a Makefile knob (either a > specific knob, or just the caller setting the right CFLAGS etc), and > then for the builds of Git for Windows to turn those knobs when making a > package to distribute. > > Our internal package builds at GitHub all have this in their config.mak > (for Linux, of course): > > CFLAGS += -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 > CFLAGS += -fstack-protector-strong > > CFLAGS += -fpie > LDFLAGS += -z relro -z now > LDFLAGS += -pie > > and I wouldn't be surprised if other binary distributors (like the > Debian package) do something similar. Yes, the Debian package uses CFLAGS := -Wall \ $(shell dpkg-buildflags --get CFLAGS) \ $(shell dpkg-buildflags --get CPPFLAGS) and then passes CFLAGS='$(CFLAGS)' to "make". That means we're using -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 Dscho's suggestion for the Windows build sounds fine to me (if checking for -Og, too). Maybe it would make sense to factor out a makefile variable for this, that could be used for builds on other platforms, too. That way, the autodetection can be in one place, and there is a standard way to override it when the user wants something else. Thanks, Jonathan
