Question

I’m trying to create a static library to use inside my PHP extension. To do that, I’m compiling my .c files using gcc -c file.c -o file.o and obtaining .o files. I then use ar rcs lib.a *.o to archive all the compiled objects into an .a file.

After doing this, I’m referring to this .a file when compiling my PHP extension, but I get the following error:

*** Warning: Linking the shared library <extension>.la against the
*** static library lib.a is not portable!

If I use the .o files instead of the .a file, I get:

*** Warning: Linking the shared library <extension>.la against the non-libtool
*** objects  file1.o file2.o is not portable!

What am I doing wrong and what’s the correct way of doing this?

Answer 1

The short answer: shared libraries (of which a PHP extension is a special case) cannot depend on static libraries.

Actually that’s not quite entirely true. As long as your static library is built as position-independent code (PIC), using it from a shared library will work; whatever .o files from the archive are needed to satisfy the undefined symbols in the .o files you explicitly linked to make the .so will get pulled in and become part of the shared library file.

Linking non-PIC .o files into a shared library will also work on some archs (like i386) but it’s not portable (and won’t work on x86_64).

As for what you should do, if it’s possible, I would just forget about the intermediate .a file and link all your .o files explicitly into the .so file for the extension. This is clean and simple. Or you could keep doing it the way you’re doing as long as you’re sure all your files got built as PIC (i.e. with the -fPIC option).

What I would not do is make and install an extra .so file that the main .so file for the extension will then depend on. All this does is create bloat, increase load time, and make lots of trouble with deployment/integration.