RE: CFLAGS/LDFLAGS for PIE vs PIC?

[John Calcote]

> -----Original Message-----
> From: address@hidden [mailto:help-
> address@hidden On Behalf Of Bryan Ischo
> Sent: Sunday, April 01, 2012 5:18 PM
> To: address@hidden
> 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