Dynamically linked shared libraries are an important aspect of GNU/Linux. They allow executables to dynamically access external functionality at run time and thereby reduce their overall memory footprint. This article investigates the process of creating and using dynamic libraries, provides details on the various tools for exploring them, and explores how these libraries work under the hood.
Post a Comment
Member since:
2005-09-20
Member since:
2006-08-02
I've had a detailed look at 2 binary formats over the years, both ELF and Microsoft's PE.
PE doesn't generate position-independent code, so it's slightly faster than ELF since eg. the EBX register is available to x86 applications to use. However each DLL has to be loaded at a particular location in memory, and that location cannot change after the DLL is loaded, so if that memory region is unavailable in a new process, the DLL has to be "rebased", ie. a new private copy of it loaded somewhere else in memory, which uses extra memory in that process.
ELF does generate position-independent code so it never has the rebasing problem, at the cost of a slight slow down in performance, but in ELF symbol lookup is process scoped, not library scoped like everywhere else. So if 2 libraries define the same symbol, the first library loaded wins. This is a big problem in real world applications, as Autopackage discovered.
Member since:2005-07-24
Yes. The difference is typically about 5% for processor-bound tasks on x86_32. I doubt the effect is measurable at all on architectures like x86_64 which are not so ridiculously register-starved.
gcc will produce non position independent code if you tell it to.
Member since:
2006-07-16
Here is a much much better and in-depth article: http://people.redhat.com/drepper/dsohowto.pdf How to write shared libraries
Edited 2008-08-27 14:17 UTC