Issue on linking Static lib to Shared lib

[DandePhaniraj]

Hi All,

I'm building a static library (openssl) and linking with a shared library.

The issue is,
I built openssl static library with out -fPIC option and in the makefile of shared library there is an option of -fPIC. When I'm compiling shared library with static library, I'm not getting any relocatable error, since static library is not built with -fPIC and shared library is compiling with -fPIC.

Please clarify me on this.

GCC version : gcc 4.0.4
OS : CentOS 5.2


Thanks,
phaniraj

[DandePhaniraj]

Hi All,

I got the solution,

The i386 architecture implicitly dereferences the frame pointer for each function .
In the 64-bit architectures, this dereferencing overhead was eliminated as an optimization.
The consequence of this optimization from a linking perspective was that unless 64-bit code is explicitly compiled as position independent code, it will produce code that is hard-coded with offsets for its execution context.

I wrote one sample application for verifying this behavior,

In 32bit,
$ gcc -c func1.c func2.c (building without -fPIC option in 32bit)
$ ls
func1.c func1.o func2.c func2.o func3.c main.c
$ gcc -shared -fPIC func1.o func2.o func3.c -o func.so
$ ls
func1.c func1.o func2.c func2.o func3.c func.so main.c
$ gcc main.c func.so
$ export LD_LIBRARY_PATH=./
$ ./a.out
Inside func1
Inside func2
Inside func3


In 64bit,
$ gcc -c func1.c func2.c (building without -fPIC option)
$ ls
func1.c func1.o func2.c func2.o func3.c main.c
$ gcc -shared -fPIC func1.o func2.o func3.c -o func.so
/bin/ld: func1.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
func1.o: could not read symbols: Bad value
collect2: ld returned 1 exit status

Rebuilding with -fPIC option
$ gcc -fPIC -c func1.c func2.c (building with -fPIC option)
$ gcc -shared -fPIC func1.o func2.o func3.c -o func.so
$ cc main.c func.so
$ export LD_LIBRARY_PATH=./
$ ./a.out
Inside func1
Inside func2
Inside func3

Thanks to all who try to look into the issue.


Thanks,
phaniraj

[oz]

Thanks to all who try to look into the issue.

Thank you, phaniraj, for posting back with the solution!

[Rubberman]

This issue is well known on Unix systems where linking static libraries built without the PIC option to shared libraries would cause much the same problem With some 3rd party libraries we were using at a previous job we had to get the vendor to fix that because we had to embed their libraries in our shared libraries that plugged into our commercial applications only if the customer purchased that option. Since we didn't ship source or linkable objects for the main programs/servers, the only way to do this is via shared libraries that could be dynamically loaded, hence the problem with non-PIC static libraries.