> So why shouldn't you be able to load an unshared lib (without PIC) > dynamically? Sure there still would be some additional steps.
I am not talking specifically about PIC/non-PIC code here. PIC is relevant because when you're doing dynamic loading you generally cannot predict at what (virtual) address in the process space the loaded object will end up at. That said, whether you can dynamically load non-PIC code depends on the specific architecture (e.g. on x86 you can have non-PIC code in shared objects, albeit at the price of the dynamic linker having to patch all relocations in the loaded object, while on amd64 you can't because the ABI allows certain kinds of relocations in non-PIC code which cannot be handled this way.). What I am saying is that there is no way to dynamically load code from a .a file, at least not with the system tools, period. There are reasons for this: first, a .a is not a "real" library but a collection of independent compiled objects (building a .a does not entail any kind of linking: it's about the same as tar'ing .o files together). Moreover, the dynamic linker (ld.so) needs a certain amount of information about the contents of any object it has to load: this information is stored in specific ELF sections and is computed and written by the "standard" linker (ld) when it builds the shared object from its components. andrea
