Why does gcc not implicitly supply the -fPIC flag when compiling static libraries on x86_64

user_153865 0
Viewed 25581

I've had numerous problems compiling shared objects that link statically against static libraries. This problem only shows up on x84_64 platforms. When doing the same compilation work on x86_32 I do not have any problems.

Perhaps this is a OS specific GCC configuration thing, but my research indicates that its how GCC works on x86_64 platforms. Anyhow, I am using gcc 4.4.3 on Ubuntu 10.04 x86_64.

How is the problem fixed ?... Making sure all the static library dependencies are compiled with -fPIC.

Question 1: What is the difference between -fpic and -fPIC (apparently -fPIC generates more instructions on x86) ? Why is the later type more relevant in the x86_64 context ?

Question 2: My assumption is that when you link against static code you are hard-wiring the functions into your binary at link time, why does it need the level of indirection the "position independant code" machinery provides ?

Question 3: Now if x86 doesn't need -fpic / -fPIC to link shared objects against static archives why is it needed in x86_64 ?

Question 4: even if it is needed why isn't it supplied implicitly ? I thought breaking changes was supposed to be a big no-no

gnu-toolchain dynamic-linking static-linking compilation gcc
2 Answers

A typical .a static library is just a collection of regular .o objects

Therefore, conceptually, you can normally just replace the .a with the exact same list of .o files on the command line, which do not need to be relocatable.

Consider for example this minimal runnable example:

a.c

#include "a.h"

int a(void) { return 1; }

a.h

#ifndef A_H
#define A_H

int a(void);

#endif

b.c

#include "b.h"

int b(void) { return 2; }

b.h

#ifndef B_H
#define B_H

int b(void);

#endif

main.c

#include <assert.h>
#include <stdlib.h>

#include "a.h"
#include "b.h"

int main(void) {
    assert(a() == 1);
    assert(b() == 2);
    return EXIT_SUCCESS;
}

Compile and run:

gcc -ggdb3 -std=c89 -Wall -Wextra -pedantic-errors -fPIC -c 'main.c' -o 'main.o'
gcc -ggdb3 -std=c89 -Wall -Wextra -pedantic-errors -fPIC -c 'a.c' -o 'a.o'
gcc -ggdb3 -std=c89 -Wall -Wextra -pedantic-errors -fPIC -c 'b.c' -o 'b.o'
ar rcs ab.a a.o b.o
gcc -ggdb3 -std=c89 -Wall -Wextra -pedantic-errors main.o ab.a -o maina.out
./maina.out

From this we see clearly that ar simply packs a.o and b.o into ab.a.

As a result, the following command also works:

gcc -ggdb3 -std=c89 -Wall -Wextra -pedantic-errors main.o a.o b.o -o maina.out

From this it should hopefully be clear that there is no need to make the object files inside the .a archive be position independent in general.

You could make them position independent if you wanted e.g. to link them into a shared library for example. Everything applies as before: the .a just contains them without modifying them.

This answer may also be of interest: What is the -fPIE option for position-independent executables in gcc and ld?

Tested on Ubuntu 20.04.

user_8952450
Related