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

Question

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 compi

Answer 1

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.

Answer 2

1. See question 3544035. Also discussed here and there.
2. It depends on what use you will have for your static library. If you only want to link it into programs, it doesn't need PIC code (libtool calls that a convenience library, because you could pretty much do without it, it simply helps get your compilation process to a reasonable size, for example). Otherwise, if you intend to link shared libraries against it, you need PIC code in your static library.
3. See question 3146744 and also here
4. It bloats your code, so it's not the default. One thing to see is that, when you compile a single object file, GCC doesn't know if you're going to create a shared library out of it or not. In most of my smaller projects, I simply link together a couple of object files, and do not need PIC code, for example.

Also, my advice would be: if you need to worry about that, you're doing it wrong (or you like to learn the hard way, which is nice because you'll get more out of the experience). Compilation systems (libtool, cmake, whatever you use) should do that for you.