PhobosV3+ Fundamental Elements

[Gregor Mückl]

On Saturday, 19 September 2026 at 18:27:24 UTC, Richard (Rikki) 
Andrew Cattermole wrote:
> On 20/09/2026 6:04 AM, Gregor Mückl wrote:
>> Also, another scenario that I believe is full of nasty 
>> surprises is when two shared libraries get loaded dynamcially 
>> by a process at runtime that are built with different version 
>> of Phobos. Even if the file names don't collide, the symbol 
>> names will because they have to be exported. If Phobos was 
>> linked statically into each shared library with hidden symbol 
>> visiblity, those issues would go away.
>
> Unless you are doing something more advanced build setup wise, 
> you would also be using different compilers and druntimes too. 
> That is not meant to work.

The presence of a different version of a library in the same 
process can be something that is completely out of the control of 
the affected developer. I can give you a few examples of how this 
kind of stuff can get really uncontrollable:

- Vulkan specifies a dynamic loading scheme for layers that 
intercept API calls between the application and the driver. The 
landscape for these kinds of layers has evolved into a not quite 
lawless wild west. Drivers and a lot of applications that you 
would otherwise not expect ship layers that get loaded into 
*your* program's address space when you create a Vulkan instance. 
There's nothing you can do about that - the loader doesn't have 
an off switch for this behavior by design. Steam and OBS are 
examples for programs that ship such Vulkan layers.

- Your product is a plugin for some big application like Word or 
Revit or Unity... you have no control over what those programs 
are going to load alongside your own plugin.

These are definitely situations where the modules that get loaded 
need to be as self-contained and isolated as possible to try and 
avoid funky issues.