Big picture on shared libraries when they go wrong, how?

[Paulo Pinto]

On Wednesday, 8 May 2024 at 05:13:55 UTC, Gregor Mückl wrote:
> On Wednesday, 8 May 2024 at 03:08:15 UTC, Walter Bright wrote:
>> Thanks for writing this.
>>
>> Are you writing solely about DLLs on Windows? They don't have 
>> much in common with shared libraries on OSX and Posix.
>
> That is confusing me as well. DLLs share concepts with shared 
> libraries on other platforms, but they have subtle differences. 
> The ones that come to my mind:
>
> - Shared libraries export everything by default. DLLs export 
> nothing by default. This relates to the non-standard 
> declspec(dllexport) declaration supported by MSVC to mark 
> exported symbols.
>
> - Unix system linkers take shared libraries as input files 
> directly. Windows linkers require import libraries. These 
> import libraries contain thunks that jump to the real code in 
> the DLL. Those thunks can be avoided if the compiler knows a 
> symbol comes from a DLL. This is why declspec(dllimport) exists 
> in MSVC (as a performance optimization).
>
> - DllMain() is a Windows only construct. If it is present, it 
> is invoked for a lot of different events (PROCESS_ATTACH, 
> THREAD_ATTACH...). Some Unix/Posix OSes support callbacks for 
> loading/unloading libraries at most. The mechanisms are not 
> equivalent.
>
> - And then there are all the funny ways in which static 
> initialization in C++ can break in combination with Unix shared 
> libraries. There are some fun, really opaque pitfalls like 
> static constructors getting executed multiple times (and at 
> times when you probably woudldn't expect). I don't think the 
> same is true on Windows.
>
> These differences result in a number of things that are 
> different in one model and not the other. On Unix, it's legal 
> to have name collisions between symbols exported from different 
> libraries. Typically, the first encountered symbol wins. This 
> allows mechanisms like LD_PRELOAD to work and and use a program 
> with a replacement malloc() implementation, for example. There 
> is no Windows equivalent for this. You'd have to provide a shim 
> DLL in the search path that provides all symbols.


This is also not fully correct.

The Windows DLL model is also present on Aix, including having 
export files, and similar kind of linker features. While Aix 
adopted ELf later on, COFF is still quite prevalent, having 
evolved into XCOFF.

Although no longer relevant, Symbian also used the same DLL model.

Then we Amiga Libraries, BeOS, IBM i, IBM z and Unisys ClearPath 
MCP, all of which are kind of their own thing.

While they all might be irrelevant for D, there is a bit more to 
shared libraries as only POSIX vs Windows.