Dynamic Linking Best Practices
begriffs.com
Dynamic Linking Best Practices
1–10 of 12 posts
Re: Dynamic Linking Best Practices
#2> The design typically used nowadays for dynamic linking (in BSD, MacOS, and Linux) came from SunOS in 1988. The paper Shared Libraries in SunOS neatly explains the goals, design, and implementation.
Aix shared libraries follow a model similar to Windows, with export files.
https://www.ibm.com/docs/en/aix/7.2?topic=memory-creating-sh...
https://www.ibm.com/docs/en/aix/7.2?topic=formats-xcoff-obje...
Re: Dynamic Linking Best Practices
#3Compiling a shared lib means adding 'fpic', which can mean poor codegen if you don't handle your symbol visibility well. By default symbols are globally visible and the compiler must assume that at runtime you may do an LD_PRELOAD in order to hook into some functions, and to do that the functions need to be called indirectly rather than directly.
At the very least, add '-fvisibility-inlines-hidden'.
Re: Dynamic Linking Best Practices
#4This article is a superb treasure trove of experience on dynamic linking. Thanks for sharing this gem.
Re: Dynamic Linking Best Practices
#5Very interesting. There was also the old Drepper paper, which was very good but this seems more accessible. [1]
Re: Dynamic Linking Best Practices
#6Compiling a shared lib means adding 'fpic', which can mean poor codegen if you don't handle your symbol visibility well. By default symbols are globally visible and the compiler must assume that at runtime you may do an LD_PRELOAD in order to hook into some functions, and to do that the functions need to be called indirectly rather than directly. At the very least, add '-fvisibility-inlines-hidden'.
[deleted]
Re: Dynamic Linking Best Practices
#7As someone who's just now diving into low-level programming on unix, this article is just what I needed.
Saving this for future reference.
Re: Dynamic Linking Best Practices
#8It is good article, but I wish it discussed the differences in dynamic symbol resolution, which is often a source of subtle compatibility issues when porting between POSIX OSes.
Linux uses a flat namespace for linking, where each bind lists the symbol name, and then at runtime ld.so searches for that symbol based on the library search order.
macOS uses a two level namespace for linking, where each bind lists both the symbol name and the installname of the library that provides the symbol. This means at runtime the dynamic linker does not need use a library search path. This has a number of performance and binary compatibility benefits, though it can make building software a bit more complex.
Solaris uses a flat namespace, but retrofitted two levelnamespace semantics via Direct Binding[1][2]. I am not sure how pervasively they are used.
I know there were some efforts to port Solaris Direct Binding support to Linux maybe 15 years ago[3][4], but it is a very hard change to make without breaking bin and source compatibility for projects that depend on insert libraries in the search path for partial refinements via interposing symbols.
1: https://en.wikipedia.org/wiki/Direct_binding 2: http://www.linker-aliens.org/blogs/ali/entry/the_cost_of_elf... 3: https://lwn.net/Articles/192624/ 4: https://bugs.gentoo.org/114008
Re: Dynamic Linking Best Practices
#9How this compares to Windows? IIRC it is all handled by the executable itself?
The kernel32.dll is loaded at known address and it has LoadLibrary function to get a handle of DLL and GetProcAddress that resolves a function name to a function pointer. It loads DLLs from the working directory or system directories. No versioning. (But there are some compatibility tricks to provide correct version of the library even when the dll name does not change)
Re: Dynamic Linking Best Practices
#10How this compares to Windows? IIRC it is all handled by the executable itself? The kernel32.dll is loaded at known address and it has LoadLibrary function to get a handle of DLL and GetProcAddress that resolves a function name to a function pointer. It loads DLLs from the working directory or system directories. No versioning. (But there are some compatibility tricks to provide correct version of the library even whe…
I thought it was handled by ntdll.dll at the end of the day with the Ldr* set of functions. LoadLibrary ends up calling into that, but initial process load calls Ldr* without a LoadLibrary call.