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

Fri May 10 02:05:18 UTC 2024

On 10/05/2024 10:04 AM, Atila Neves wrote:
> On Monday, 6 May 2024 at 03:28:47 UTC, Richard (Rikki) Andrew Cattermole 
> wrote:
>> This post is meant to be a highly enlightening and entertaining 
>> explanation (or should I say it shouldn't cure anyones insomnia) of 
>> just how many things can go wrong with shared libraries if they are 
>> not worked with right regardless of platform.
>>
>> [...]
> 
> There were a few things here I didn't understand; sometimes whole 
> sentences. I don't know what "siblings shared libraries" are, and 
> "intermediary static libraries" only made sense to me further down when 
> I understood that it was about linking several static libraries into a 
> dynamic one.
> 
> Some questions:
> 
> On everything druntime-related, how is it done in C++? C (unless 
> freestanding) and C++ both have runtimes despite some people pretending 
> otherwise.

You use the shared library build of it by default.

You can opt into using a switch to use a static library instead, but you 
are on your own.

This reflects my recommendations.

Oh hey, similar recommendations I gave can be found here: 
https://learn.microsoft.com/en-us/cpp/c-runtime-library/crt-library-features?view=msvc-170#what-problems-exist-if-an-application-uses-more-than-one-crt-version

"When you build a release version of your project, one of the basic C 
runtime libraries (libcmt.lib, msvcmrt.lib, msvcrt.lib) is linked by 
default"

libcmt.lib	Statically links the native CRT startup into your code.

msvcmrt.lib	Static library for the mixed native and managed CRT startup 
for use with DLL UCRT and vcruntime.

msvcrt.lib	Static library for the native CRT startup for use with DLL 
UCRT and vcruntime.

> "you cannot tell the compiler that a module is not in your binary." - 
> isn't this exactly what happens with `export` on a declaration (as 
> opposed to a definition)? That is, my understanding is that `export` 
> with no body means `dllimport` and `export` with a body means `dllexport`.

Keep in mind that nobody that I know of is using it to mean this today.

Also a D module may be in binary, but it may have declarations that 
point to something that is not.

See the bindings in druntime where it has D symbols.

https://github.com/dlang/dmd/blob/5fc02ba152ccaa71711f3ed84b6d44a2a940f206/druntime/src/core/stdc/stdio.d#L1191

This is why you don't pretend that one symbol in ``DllImport`` mode 
means the entire module is because it may be a binding to something else.

Note: there are plenty of examples of it which are not templated, like 
structs that have to be initialized using the D init array.

> Where does the need for "private but export" come from again? Is there 
> an equivalent in C++ (`static dllexport`?), or does this only happen due 
> to something specific to D like `T.init`?

It happens because D confuses exportation which is a linker concept, 
with a language visibility concept.

In C/C++ it uses a completely separate attribute to donate that it does 
not affect Member Access Control such as ``private``.

But you can see this with things like templates, you want to access an 
internal symbol but don't want somebody else to? Yeah no, can't do that 
today.

https://learn.microsoft.com/en-us/cpp/cpp/dllexport-dllimport?view=msvc-170

You have to be very explicit in c/c++ over this, we do not have that 
level of control (apart from saying do not export this symbol via 
``@hidden``).

> "By not exporting ModuleInfo and assuming it is available the compiler 
> introduces a hidden dependency on a generated symbol that may not 
> exist." - do we have an issue for that? I searched for ModuleInfo in the 
> issues but none of them looked like a match to me.

Yes two. They are referenced in the article.

Note: they are not duplicates.

Okay I lie there is a bunch more.

https://issues.dlang.org/show_bug.cgi?id=23850

https://issues.dlang.org/show_bug.cgi?id=23177

https://issues.dlang.org/show_bug.cgi?id=23974

https://issues.dlang.org/show_bug.cgi?id=6019

https://issues.dlang.org/show_bug.cgi?id=9816

Here is my workaround code to get around this problem: 
https://github.com/Project-Sidero/basic_memory/blob/main/source/sidero/base/moduleinfostubs.d

Not something I am proud of needing.