pkgsrc-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: PKGSRC_MKPIE question



On Tue, 22 Oct 2024 20:00:11 +0000
nia <nia%NetBSD.org@localhost> wrote:

> On Tue, Oct 22, 2024 at 05:40:30PM +0100, Sad Clouds wrote:
> > However, GCC man page talks about two separate options:
> > 
> > -fPIC used for position independent libraries
> 
> There is a reason GCC's documentation talks about -fPIC being
> "for shared libraries" and it's mostly a legacy matter. Shared libraries
> require you to generate position-independent code. However, there's
> reasons you might want to use PIC for a regular executable:
> 
> (a) to make ASLR more effective
> (b) because your architecture's ABI requires it
> 
> You are correct in assuming that telling whether a shared
> library or regular executable is being generated is A Hard Problem.
> Particularly, many shared object file formats exist, and a build
> system may reuse compiled object code and then link it into
> _both_ a library and an executable.  Note that -fPIC is a
> compiler flag, not a linker flag.

OK thanks for the info. I'm looking at existing Makefiles and pkgsrc to
see how people handle PIE executables. My understanding is that GCC
flags '-fpie' and '-fPIE' should only be used for executables, where
flags '-fpic' and '-fPIC' are safe to use for both, executables and
shared libraries.

The problem is, variables like CFLAGS are normally applied to all object
files, so sticking -fPIE there may not work well. It looks like pkgsrc
simplifies this by always using '-fPIC' and then only passing '-pie' to
the linker LDFLAGS, which only gets invoked when building executables.

I think I will take a different approach in my Makefiles. Setup a
separate variable like 'USE_PIE' and then conditionally append to
CFLAGS and LDFLAGS, depending on which object files are built. GNU
make has target specific variables, which may help here.


Home | Main Index | Thread Index | Old Index