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

[Atila Neves]

On Friday, 10 May 2024 at 02:05:18 UTC, Richard (Rikki) Andrew 
Cattermole wrote:
>
> 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.
>>>
>>> [...]
>> 

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

Maybe the recommendation should then be that they should? Doesn't 
the point still stand that "you cannot tell the compiler that a 
module is not in your binary" isn't actually true? I saw in one 
issue where there was a problem with variable declaration though, 
where dllimport/dllexport was determined by the presence or not 
of an initialiser, which is... yuck.

> 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

The relevant code is:

     private extern shared FILE[3] __sF;
     @property auto stdin()() { return &__sF[0]; }

`__sF` is declared extern, i.e., not in binary. I don't 
understand what the issue would be?

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

Why would the entire module be dllimport?

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

Yes, but I don't know how this is related to the above.

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

My question is: when would I want to export a private symbol?

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

On Windows, C/C++ compilers use a non-standard extension to do 
so, but yes. AFAIK (and I could well be wrong), one can't 
dllexport something that's static? You'd have to put it in a 
header, and it'd be compiled into the current translation unit 
anyway, so I also don't understand why you'd want to.

> 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

Assuming the link is supposed to elucidate the template comment, 
I don't understand the relevance. Otherwise, what does "you want 
to access an internal symbol but don't want somebody else to" 
mean?

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

This could mean several things. We have the control over 
individual symbols that are actually in the source code with 
`export`. Is the comment above about things like T.init?

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

Thanks!

On a somewhat related note, we use dlls at work and seem to have 
fixed "everything" by using ldc and `-fvisibility=hidden 
-dllimport=defaultLibsOnly`, as well as `-link-defaultlib-shared`.