And who is responsible for it?

I had issues with shared library initialization functions being executed only sometimes. That would result in shared library features not registering themselves with the loading program. (It would work when D program loaded it but not when C++ loaded the D library.)

I opened a couple of forum threads about this but luckily I worked around the issue.

My question is related to something a colleague told me today: A shared library's initialization function is not guaranteed to be called unless a feature of a library is actually used. This page seems to describe the same issue:

  http://interreality.org/~reed/dylib_init.html

Although that page thinks this issue may not be relevant anymore, the fact that my colleague had it with a recent C++ version tells me its still current.

What do you know about this? Is this the same in D? Is this simply a loader (linker?) issue, which would affect any language?

Thank you,
Ali

On Thursday, 22 July 2021 at 07:09:31 UTC, Ali Çehreli wrote:
> And who is responsible for it?
>
> I had issues with shared library initialization functions being executed only sometimes. That would result in shared library features not registering themselves with the loading program. (It would work when D program loaded it but not when C++ loaded the D library.)
>
> I opened a couple of forum threads about this but luckily I worked around the issue.
>
> My question is related to something a colleague told me today: A shared library's initialization function is not guaranteed to be called unless a feature of a library is actually used. This page seems to describe the same issue:
>
>   http://interreality.org/~reed/dylib_init.html
>
> Although that page thinks this issue may not be relevant anymore, the fact that my colleague had it with a recent C++ version tells me its still current.
>
> What do you know about this? Is this the same in D? Is this simply a loader (linker?) issue, which would affect any language?
>
> Thank you,
> Ali

This is very OS specific.

On Windows, it makes a difference if the DLL is an old style DLL, or is making use of COM, because in addition to the raw DLLs behaviours, COM introduces threading execution appartments, and can execute either in-proc or external process (in same machine or over the network, e.g. DCOM).

Basically if you want to control initilization code, you need to provide a DllMain function, which gets called, when the library is loaded for the very first time, when it is mapped into other execution threads contexts or shared with other processes.

https://docs.microsoft.com/en-us/windows/win32/dlls/dllmain

https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-best-practices

In general POSIX shared libraries behave in a different way, however certain UNIX variants like AIX, do have Windows like capabilities for their shared libraries.

Then there are all the other OSes that aren't either POSIX nor Windows based, like the aging mainframes and micro-computers.

Naturally on top of this, you have to map possible interoperabilitiy issues with the D runtime for the said OSes.