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