I have been building with -fstack-protector in GCC 4.1 lately, and discovered that I need it in CFLAGS and LDFLAGS. This works with almost every package except a few. htmltidy is one of these. The optional htmldb subdir, included by use xml, has a very simple Makefile that does not use LDFLAGS in its link steps. Easy fix, just include $(LDFLAGS) on the link lines.
Reopen with some errors you get, I don't understand this bug. Stuff like -fstack-protector doesn't belong into LDFLAGS; also using this thing globally in C[XX]FLAGS is just asking for trouble.
(In reply to comment #1) > Reopen with some errors you get, I don't understand this bug. Stuff like > -fstack-protector doesn't belong into LDFLAGS; also using this thing globally > in C[XX]FLAGS is just asking for trouble. Well, after looking at the problem again, I see that I was wrong about the cause here. So leave this bug closed. But to answer your question, -fstack-protector needs to be in CFLAGS so that it is built into the objects, and it needs to be in LDFLAGS because many makefiles do not use CFLAGS when linking the object files into the executable. It needs to be specified for both compile and link stages because it needs to link in libraries as well as adding code using those libraries to each function call. I don't understand why you feel it is a bad idea to use this flag globally. It hasn't caused me any major problems so far beyond forcing me to rebuild some applications that depend on libraries that were rebuilt with the flag.