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 architectures too. 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. Tim
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.
Thanks, fixed.