> 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.<p>Aix shared libraries follow a model similar to Windows, with export files.<p><a href="https://www.ibm.com/docs/en/aix/7.2?topic=memory-creating-shared-library" rel="nofollow">https://www.ibm.com/docs/en/aix/7.2?topic=memory-creating-sh...</a><p><a href="https://www.ibm.com/docs/en/aix/7.2?topic=formats-xcoff-object-file-format" rel="nofollow">https://www.ibm.com/docs/en/aix/7.2?topic=formats-xcoff-obje...</a>
Compiling 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.<p>At the very least, add '-fvisibility-inlines-hidden'.
Very interesting. There was also the old Drepper paper, which was very good but this seems more accessible. [1]<p>[1] <a href="https://akkadia.org/drepper/dsohowto.pdf" rel="nofollow">https://akkadia.org/drepper/dsohowto.pdf</a>
How 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)
It 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.<p>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.<p>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.<p>Solaris uses a flat namespace, but retrofitted two levelnamespace semantics via Direct Binding[1][2]. I am not sure how pervasively they are used.<p>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.<p>1: <a href="https://en.wikipedia.org/wiki/Direct_binding" rel="nofollow">https://en.wikipedia.org/wiki/Direct_binding</a>
2: <a href="http://www.linker-aliens.org/blogs/ali/entry/the_cost_of_elf_symbol/" rel="nofollow">http://www.linker-aliens.org/blogs/ali/entry/the_cost_of_elf...</a>
3: <a href="https://lwn.net/Articles/192624/" rel="nofollow">https://lwn.net/Articles/192624/</a>
4: <a href="https://bugs.gentoo.org/114008" rel="nofollow">https://bugs.gentoo.org/114008</a>
Good coverage of dynamic linking, but for this part:<p>> To solve these problems, I suggest bundling all development (linking) library files together into a different directory structure per version.<p>Isn't it almost exactly what's called "framework" on macOS (author's proposed structure is different, but the idea looks the same)?