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?

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

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

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

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