Does one still need to use -fPIC when compiling with GCC?

Question

On gcc target machines, when one wanted to compile a shared library, one would need to specify -fpic or -fPIC to get things to work correcly. This is because by default absolute addressing was used, which is suitable for executable that have full control of their own address space, but not shared libraries, which could be loaded anywhere in an executable's address space.

However modern kernels are now implementing address space randomization and many modern architectures support PC relative addressing. This all seems to make the absolute addressing either unusable (address space randomization) or unneeded (PC relative addressing).

I have also noticed that clang does not have an -fPIC option which makes me think that it is no longer necessary.

So is -fPIC now redundant or does one need to generate separate .o files, one for static library use, and one for shared library use?

Answer 1

You still need to compile with -fPIC. The problem isn't solvable with pc-relative addressing. The problem is how you resolve external symbols. In a dynamically linked program the resolution follows different rules and especially with adress space randomization it can't be resolved during link time.

And clang does have the -fPIC flag just like gcc.

$ cat > foo.c
void foo(void);
void bar(void) { foo(); }
$ gcc -S foo.c && grep call.*foo foo.s
    call    foo
$ gcc -fPIC -S foo.c && grep call.*foo foo.s
    call    foo@PLT
$ clang -S foo.c && grep call.*foo foo.s
    callq   foo
$ clang -fPIC -S foo.c && grep call.*foo foo.s
    callq   foo@PLT
$

Answer 2

I agree with you: in many cases the -fpic/-fPIC options are almost redundant, I do however use them to ensure:

• portability (never sure what particular OS/kernel will be available)
• backwards compatibility: with those options it ensures the behaviour you want on older kernels
• habit - Hard things to break :)
• compliance with older codebases that may require it