> 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...

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.

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]

[1] https://akkadia.org/drepper/dsohowto.pdf

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)

First of all it depends if it is a old style DLLs, or one that contains COM, as COM adds more execution models.

Additionally, applications can be packaged as DLLs and executed with help of rundll, after being loaded.

Manifests that control the loading process, besides the default way have been added in XP,

https://docs.microsoft.com/en-us/windows/win32/sbscs/applica...

Versioning in DLLs have been sorted out with SxS manifests, also in XP,

https://docs.microsoft.com/en-us/windows/win32/sbscs/isolate...

Previously versioning was sorted with VERSION resource scripts and expecting that developers actually cared about them, which most did not, hence the way .NET does versioning, and the latter improvements with manifest files for the dynamic linker.

https://docs.microsoft.com/en-us/windows/win32/menurc/using-...

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.

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.

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

Good coverage of dynamic linking, but for this part:

> To solve these problems, I suggest bundling all development (linking) library files together into a different directory structure per version.

Isn't it almost exactly what's called "framework" on macOS (author's proposed structure is different, but the idea looks the same)?

This article is a superb treasure trove of experience on dynamic linking. Thanks for sharing this gem.

As someone who's just now diving into low-level programming on unix, this article is just what I needed.

Saving this for future reference.