• Carl Sturtivant (16/16) Mar 15 2014 Back at 2.062 I was able to force the whole of D's runtime/phobos
• Mathias LANG (11/27) Mar 16 2014 DMD started to support shared lib on linux from 2.063.
• Carl Sturtivant (13/23) Mar 16 2014 Thanks, I guess I will have to go that route as my old trickery
• Carl Sturtivant (18/28) Mar 16 2014 Thanks for all that information. I did some work, and formed the
• Carl Sturtivant (8/25) Mar 18 2014 On Ubuntu amd64 I found that no special build of a C client that

"Carl Sturtivant" <sturtivant gmail.com> writes:

Back at 2.062 I was able to force the whole of D's runtime/phobos 
into an executable which was exactly what I wanted for a specific 
project containing not just D but around 50,000 lines of C. (This 
is to do with having dynamic libraries link back to the 
executable when they're loaded with dlopen, so they don't need 
their own runtime/phobos on board.) However, at 2.065 this 
doesn't happen any more. I need this same linkage with 2.065. 
Previously I used

    -Wl,--whole-archive -lphobos2 -Wl,--no-whole-archive

on a gcc command line to link all the objects in the project 
along with libphobos2, with

    -lcurl -lpthread -lm -lrt

to satisfy that linkage, and this had the desired effect. But now 
this doesn't do the job of linking the whole of D's runtime & 
phobos any more. Any suggestions how I can get the old result 
with 2.065?

"Mathias LANG" <pro.mathias.lang gmail.com> writes:

On Sunday, 16 March 2014 at 02:12:37 UTC, Carl Sturtivant wrote:
 Back at 2.062 I was able to force the whole of D's 
 runtime/phobos into an executable which was exactly what I 
 wanted for a specific project containing not just D but around 
 50,000 lines of C. (This is to do with having dynamic libraries 
 link back to the executable when they're loaded with dlopen, so 
 they don't need their own runtime/phobos on board.) However, at 
 2.065 this doesn't happen any more. I need this same linkage 
 with 2.065. Previously I used

    -Wl,--whole-archive -lphobos2 -Wl,--no-whole-archive

 on a gcc command line to link all the objects in the project 
 along with libphobos2, with

    -lcurl -lpthread -lm -lrt

 to satisfy that linkage, and this had the desired effect. But 
 now this doesn't do the job of linking the whole of D's runtime 
 & phobos any more. Any suggestions how I can get the old result 
 with 2.065?

DMD started to support shared lib on linux from 2.063.
This may be useful: http://dlang.org/dll-linux.html
Also note that if you are only writting the shared lib and not 
the client, it would be easyier to bootstrap it using gcc's 
attributes (see 
http://stackoverflow.com/questions/9759880/automatically-executed-functions-when-load
ng-shared-libraries 
).
Else, there is a Runtime.loadLibrary (which will be improved 
later), to load and start a D shared library (if you just dlopen, 
static ctor & stuff won't be initialized).

"Carl Sturtivant" <sturtivant gmail.com> writes:

 DMD started to support shared lib on linux from 2.063.
 This may be useful: http://dlang.org/dll-linux.html
 Also note that if you are only writting the shared lib and not 
 the client, it would be easyier to bootstrap it using gcc's 
 attributes (see 
 http://stackoverflow.com/questions/9759880/automatically-executed-functions-when-load
ng-shared-libraries 
 ).
 Else, there is a Runtime.loadLibrary (which will be improved 
 later), to load and start a D shared library (if you just 
 dlopen, static ctor & stuff won't be initialized).

Thanks, I guess I will have to go that route as my old trickery 
no longer works; I am building the client, so I'll now use 
Runtime.loadLibrary. However, http://dlang.org/dll-linux.html 
says I must link to libphobos.so and not libphobos.a suggesting 
that my old trickery could work as before by putting libphobos.a 
in its entirety into the client and none of it in a dynamic 
library. Yet it does not, as revealed immediately by the client's 
file size. Which suggests that http://dlang.org/dll-linux.html is 
out of date.

Can anyone tell me if http://dlang.org/dll-linux.html correct for 
2.065 ?


All of this was a lot easier on Windows, where I was able to make 
everything work with no significant trouble.

"Carl Sturtivant" <sturtivant gmail.com> writes:

 DMD started to support shared lib on linux from 2.063.
 This may be useful: http://dlang.org/dll-linux.html
 Also note that if you are only writting the shared lib and not 
 the client, it would be easyier to bootstrap it using gcc's 
 attributes (see 
 http://stackoverflow.com/questions/9759880/automatically-executed-functions-when-load
ng-shared-libraries 
 ).
 Else, there is a Runtime.loadLibrary (which will be improved 
 later), to load and start a D shared library (if you just 
 dlopen, static ctor & stuff won't be initialized).

Thanks for all that information. I did some work, and formed the 
following conclusions.

I can now confirm that the part of the document
http://dlang.org/dll-linux.html
about loading D dynamic libraries from a D main program is 
experimentally apparently correct with a real world largish 
executable.

The machinery to initialize the runtime in the dynamic library in
http://stackoverflow.com/questions/9759880/automatically-executed-functions-when-loading-shared-libraries
is apparently unnecessary in this case, though I have seen some 
hints it may be necessary when having a C main program load a D 
dynamic library.

If you want a D dynamic library to call-back functions in the D 
main program that loaded it, you may need to supply the linker 
with the -export-dynamic flag (on the dmd command line with 
-L-export-dynamic ) so as to expose symbols in the main program 
for automatic linkage to the dynamic library at the point it is 
loaded. This worked nicely for me.

"Carl Sturtivant" <sturtivant gmail.com> writes:

 I can now confirm that the part of the document
 http://dlang.org/dll-linux.html
 about loading D dynamic libraries from a D main program is 
 experimentally apparently correct with a real world largish 
 executable.

 The machinery to initialize the runtime in the dynamic library 
 in
 http://stackoverflow.com/questions/9759880/automatically-executed-functions-when-loading-shared-libraries
 is apparently unnecessary in this case, though I have seen some 
 hints it may be necessary when having a C main program load a D 
 dynamic library.

 If you want a D dynamic library to call-back functions in the D 
 main program that loaded it, you may need to supply the linker 
 with the -export-dynamic flag (on the dmd command line with 
 -L-export-dynamic ) so as to expose symbols in the main program 
 for automatic linkage to the dynamic library at the point it is 
 loaded. This worked nicely for me.

On Ubuntu amd64 I found that no special build of a C client that 
loads a D dynamic library using dlopen (etc) is necessary for 
callback linkage from the library to the client. So 
-export-dynamic is unnecessary! However, the machinery mentioned 
here
http://stackoverflow.com/questions/9759880/automatically-executed-functions-when-loading-shared-libraries
IS necessary so that the runtime in the dynamic library is 
initialized when it is loaded.