PhobosV3+ Fundamental Elements

[Richard (Rikki) Andrew Cattermole]

On 20/09/2026 6:04 AM, Gregor Mückl wrote:
> On Friday, 18 September 2026 at 16:46:36 UTC, Richard (Rikki) Andrew 
> Cattermole wrote:
>> On 18/09/2026 7:16 PM, Gregor Mückl wrote:
>>> Please include an option to have all these libraries statically 
>>> linked as well. Sometimes, it just happens that one really, really 
>>> needs a completely self-contained binary.
>>
>> If you hit a wall like that you can always build it yourself.
>>
> 
> What should I build myself? I think your statement is a bit ambiguous. 
> Do you mean recompiling Phobos or building an entire competing standard 
> library? I'm assuming the former.

The libraries that we ship that are built on top of the base PhobosV3 
library.

PhobosV3 base library is akin to V2, we have no auxillary libraries 
built on top equivalent in V2.

>> The libraries built on top of the base phobosv3 library, need to be 
>> shared libraries they are doing things like event loop that should not 
>> be available by default and are not going to work right if they were a 
>> static library.
>>
> 
> I don't understand the event loop part at all. This seems to come out of 
> the blue. Can you give me a little more context on that?

Proper event loops are very expensive to just link in and have on.

Background threads on mass, and lots of extra dependencies.

Not a good default.

But its necessary if you want to do windowing and networking properly.

>> I don't want people who don't know what they are doing thinking that 
>> they should use a static library for easier shipping and then find 
>> themselves with core features not working.
>>
> 
> Well, a binary that needs to sit next to a bunch of libraries isn't such 
> a great deal, either.
> 
> I'm not against shared libraries as a default, but there must be a way 
> to use at least the most common part of Phobos statically linked into a 
> binary. There are quite a few use cases out there where people are 
> expected to copy e.g. single Windows DLLs around to make things work 
> (VST instruments, for example - so dplug would be impacted).

Yes, none of that is affected.

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