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

[Atila Neves]

On Tuesday, 14 May 2024 at 22:13:19 UTC, Richard (Rikki) Andrew 
Cattermole wrote:
>
> On 15/05/2024 6:19 AM, Atila Neves wrote:
>> [...]
>
> 1. Metadata (ModuleInfo, TypeInfo, RTInfo)

These are whats, not whys.

> 2. It is almost certainly going to be correct

What is most certainly correct?

> and ``-I`` is almost certainly at play, therefore we can 
> leverage this information to turn ``export`` for positive 
> annotation into ``DllImport``.

We already have a mechanism to do this.

> Can you spot the problem with this: ``[void*]`` vs ``[void*, 
> void**, void*]``

No, but I don't understand the question.

> Metadata quite literally is incapable of crossing the DLL 
> boundary without knowing if its in or out of binary. It 
> prevents linking.

What prevents linking?

>> [...]
>
> This also plays into the external import path switch, since we 
> know that is almost certainly correct, adding the extern on 
> make a very clean simple solution for positive annotation!

I don't see how `extern` is related to a potential external 
import path switch.

>> [...]
>
> Both druntime and PhobosV2 will remain in using negative 
> annotation for the foreseeable future. The amount of work to 
> convert that to positive is quite significant because its not 
> just slapping export on things, you also have to test it.

`export:`?

What needs to be tested?

> Now do the rest of the ecosystem but with people who don't know 
> what they are doing.

I think it's unlikely that most projects would need to work in 
dlls.

>> [...]
>
> So you want even more global state?

?

>> [...]
>
> What if its accessing global state (and perhaps giving you 
> access to it via callback)?
>
> What if it is global state instead of a function?
>
> What makes you think that it can be inlined?

C++.


>> [...]
>
> Some cannot be like ``ModuleInfo``, others have be exported 
> based upon if other things in the encapsulation are exported.

What's an "encapsulation"?

> Its either that or we export literally everything inside of the 
> encapsulation unit (I don't like that at all).

?

>> [...]
>
> The way I view it is as thus:
>
> - If you use D shared libraries with a static runtime, you're 
> going to have your program have indeterminate behavior.

Which doesn't seem to be what happens most often.

> - On the other hand, if you don't use shared libraries with a 
> shared runtime it works.

It doesn't seem this is what most people want.

> So from my perspective its better to be opt-in for static 
> runtime/phobos builds if you know you don't need it, than the 
> opposite.

Again, the raves from people new to Go would suggest otherwise. 
So would the lack of requests for this in D.