• =?UTF-8?Q?Ali_=c3=87ehreli?= (19/19) Jul 22 2021 And who is responsible for it?
• Paulo Pinto (20/41) Jul 22 2021 This is very OS specific.

=?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:

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

Paulo Pinto <pjmlp progtools.org> writes:

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.