Red Hat Bugzilla – Bug 6342
Shared library compiled without PIC
Last modified: 2008-05-01 11:37:52 EDT
The Makefile creates both static and shared libraries from
the same objects. Normally two sets of objects, one static
and one shared (built with -fPIC) would be produced for each
library, then linked.
On ARM this bug results in invalid relocs in the shared
library. This could very possibly cause problems on other
It should be okay to just add -fPIC to the compile flags, as
it shouldn't have an adverse affect the static libs.
Additional: the spec file also uses the very EVIL construct
of setting the build prefix to the buildroot. Although it
works, this time, this is NEVER a good idea! One of these
days it will burn you. The install prefix is what you
really want to change, which can be done in the %install
section in the make line(s).
assigning to owner of package.
The problem affects all architechtures, but is troublesome on ARM and PowerPC.
The problem stems from relocs in the text segment. In a shared library, you
cannot do the reloc because then it would screw up everyone sharing that
library. On some architectures (like x86), this is handled transparently by the
dynamic linker/loader. In this case, the text segment is copied, made
writeable, and then the reloc is done. Of course the library is no longer
really shared as there are now multiple images in memory :(
This can be implimented to some extent on ARM as well, except that the reloc
can't be over 32 MB (PC24 reloc = 26 bit offset, 4 byte aligned) as that's the
largest immediate offset allowed. So it isn't a reliable kludge.
On the other hand, PIC uses references to the GOT and PLT (PC32 relocs) which
solves the problem entirely on all architechtures.
[Perl is also an offender, as libperl.a and DynaLoader.a are not PIC, but are
linked by dynamically loaded modules like mod_perl.]
Summary: shared libraries and dynmaically loaded modules should only contain and
be linked to PIC code.