> -----Original Message----- > From: help-make-bounces+john.calcote=gmail....@gnu.org [mailto:help- > make-bounces+john.calcote=gmail....@gnu.org] On Behalf Of Bryan Ischo > Sent: Sunday, April 01, 2012 5:18 PM > To: help-make@gnu.org > Subject: Re: CFLAGS/LDFLAGS for PIE vs PIC? > > On 04/01/12 11:30, Jeffrey Walton wrote: > > Hi All, > > > > I'm interested in trying to figure out how to "cleanly" set options > > for CFLAGS (and CXXFLAGS) and LDFLAGS. I also want it to intelligently > > apply to programs and shared objects. The problem I am having is > > programs need: > > > > CFLAGS += -fPIE > > LDFLAGS += -pie > > > > while shared objects need: > > > > CFLAGS += -fPIC > > LDFLAGS += -shared > > > > So I can't run configure to set up a project properly: > > > > $ configure CFLAGS="-Wall -Wextra -Wconversion -fPIE -pie > > -Wno-unused-parameter -Wformat=2 -Wformat-security > > -fstack-protector-all -Wstrict-overflow > > -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now" > > > > I see others have also felt the same discomfort > > (http://lists.fedoraproject.org/pipermail/devel-announce/2011- > August/000821.html): > > > > "All of this is only an issue because most build systems don't > > let you say different CFLAGS or LDFLAGS for shared libraries > > and executables. Sigh." > > > > Any ideas? > > Well, I don't use GNU autoconf for my projects, so I can't address that. > What I do though is to specify different rules for object files that are to be > linked into shared libraries than those to be built into executables. I use a > different file extension for shared object files - typically, .po instead of .o - > and then specify files with this extension as being the prerequisite for shared > objects. My compile rule for building .po objects will include the -fPIC flag; > the compile rule for building .o objects will not. If I am building the same > library as both shared and static, the object files will be built twice - once as > .po and once as .o - each to be linked into the corresponding shared or static > library. Files that only ever link directly into executables are only ever built as > .o files. I find this works very well. I don't know how, or if it's possible, to > easily institute this policy in autoconf generated Makefiles. >
Perhaps I'm showing my ignorance here, but I find it difficult to understand why any source file should ever be compiled without -fPIC. Are we really worried about a few bytes of storage or memory in this day and age? This flag has been the crux of all logistical problems I've ever dealt with when building linux objects. For example, there are times when I need to build objects that will be linked statically into a program AND statically into a shared library. Do I build two static libraries: one called libutil_static.a and libutil.a? That seems silly and wasteful. Rather, I've found it simpler in this case to just build all these "util" source files with -fPIC and archive them all into one libutil.a that can be linked both into my programs and into my shared libraries. If anyone has any input, I'd love to hear good reasons for not just disregarding non-pic code these days. John _______________________________________________ Help-make mailing list Help-make@gnu.org https://lists.gnu.org/mailman/listinfo/help-make