PhobosV3+ Fundamental Elements

[Gregor Mückl]

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

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

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.