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