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

[Richard (Rikki) Andrew Cattermole]

On 08/05/2024 3:08 PM, Walter Bright wrote:
> Thanks for writing this.

I'm happy to do it.

I do sincerely hope it raises enough awareness of the situations that 
you can get into if your builds are even slightly "interesting" that we 
can have this be fully solved with some form of finality.

> Are you writing solely about DLLs on Windows?

No, although that is where I found the vast majority of problems however 
it isn't the source of them.

There is mention of ``RPATH`` and a difference in behavior of the loader 
between POSIX, OSX and Linux.

Porting my code base was fairly straight forward as the only things 
specific to Linux I had to deal with was featured in the ``TLS Hooking`` 
and ``It is Loaded, Works Yes?`` headings. Everything else was just 
system library differences basically and applying existing solutions to 
known problems found on Windows.

> They don't have much in common with shared libraries on OSX and Posix.

They do have plenty in common, this is a misconception I really want to 
get you off of. There is a dedicated heading for this ``Is a Dynamic 
Link Library a Shared Library?``.

The base level of how the linkers and loader on Windows work is still 
the traditional model that you are an expert in. External symbols to be 
found elsewhere and internal symbols found in a given binary.

If this was not the case, Optlink would not have the ability to produce 
DLL's that still work on Windows today.

Microsoft of course wasn't happy with that model and placed a bunch of 
extra behavior on top of it that I call tunings as part of their linker.

No other platform has such extreme tunings, but others do have tunings, 
which is why we no longer use the traditional model at the compiler 
level for any platform. See LLVM's IR documentation (its referenced), 
``DllImport``, ``DllExport``, ``Internal`` (there are variations of it, 
but we'll just simplify it down to internal).