I am trying to find the D runtime/standard-library object(.o)/library(.a) files inorder to link them with some foreign code (Haskell as it happens).

I am writing a program in Haskell but want to use D for some of the imperative style logic.  I expect to have a large section of code in D so I want to take advantage of the D runtime, garbage collector, and standard libraries.

I found several discussions on getting the D runtime going, so I expect that to be easy, but (obviously) I get link errors when I do not have it to link.

What is the advised way to get the object(.o)/library(.a) files for the D runtime and standard library?

Thanks!

On Sat, Aug 24, 2019 at 12:26:43AM +0000, Jonathan Levi via Digitalmars-d-learn wrote:
> I am trying to find the D runtime/standard-library
> object(.o)/library(.a) files inorder to link them with some foreign
> code (Haskell as it happens).
> 
> I am writing a program in Haskell but want to use D for some of the imperative style logic.  I expect to have a large section of code in D so I want to take advantage of the D runtime, garbage collector, and standard libraries.
> 
> I found several discussions on getting the D runtime going, so I expect that to be easy, but (obviously) I get link errors when I do not have it to link.
> 
> What is the advised way to get the object(.o)/library(.a) files for
> the D runtime and standard library?
[...]

Not sure what's the "right" approach, but you could try compiling with dmd -v to find the path(s) to the runtime libraries that you'll need to link.

Keep in mind that before calling any non-trivial D code (i.e., that uses the GC or any druntime function, including language hooks) you need to call core.runtime.rt_init first.  And preferably at shutdown call core.runtime.rt_term to cleanup.

Not sure what will happen if more than one D library does this, though. My guess is that you'll somehow need to get them all to link to (or otherwise be aware of) a single instance of the D runtime, otherwise you might get some weird runtime behaviour when the two runtimes conflict with each other.


T

-- 
Indifference will certainly be the downfall of mankind, but who cares? -- Miquel van Smoorenburg

On Saturday, 24 August 2019 at 01:19:01 UTC, H. S. Teoh wrote:
> Not sure what's the "right" approach, but you could try compiling with dmd -v to find the path(s) to the runtime libraries that you'll need to link.

Oh, cool, I managed to find them on my current system.  I would love a more portable solution though.  This should work for now.

> Keep in mind that before calling any non-trivial D code (i.e., that uses the GC or any druntime function, including language hooks) you need to call core.runtime.rt_init first.  And preferably at shutdown call core.runtime.rt_term to cleanup.

Yup.

> Not sure what will happen if more than one D library does this, though. My guess is that you'll somehow need to get them all to link to (or otherwise be aware of) a single instance of the D runtime, otherwise you might get some weird runtime behaviour when the two runtimes conflict with each other.

I should only be executing the code from one place so it should not be a problem.  But `rt_init` and `rt_term` are just C bindings[1] to `core.runtime.Runtime.initialize`[2] and `core.runtime.Runtime.terminate` which state that "Each call to initialize must be paired by a call to terminate."

[1] https://github.com/dlang/druntime/blob/master/src/core/runtime.d#L30
[2] https://dlang.org/phobos/core_runtime.html#.Runtime.initialize

On Saturday, 24 August 2019 at 00:26:43 UTC, Jonathan Levi wrote:
> I am trying to find the D runtime/standard-library object(.o)/library(.a) files inorder to link them with some foreign code (Haskell as it happens).
>
> I am writing a program in Haskell but want to use D for some of the imperative style logic.  I expect to have a large section of code in D so I want to take advantage of the D runtime, garbage collector, and standard libraries.
>
> I found several discussions on getting the D runtime going, so I expect that to be easy, but (obviously) I get link errors when I do not have it to link.
>
> What is the advised way to get the object(.o)/library(.a) files for the D runtime and standard library?
>
> Thanks!

Okay,

It looks like what needs to be found are "libphobos2" and "libdruntime".  They can be found where ever your system puts lib files.  Windows (as far as I know) does not have a joined place for lib files so you need to look where dmd/ldc/etc installed itself.  On Linux lib files are generally put in `/usr/lib`.  Ideally the hunting for lib files should be left to a build tool in order to be system agnostic.  In Cabal (Haskell's build tool) add "druntime" and "phobos2" to `extra-libraries`.

On Saturday, 24 August 2019 at 02:10:19 UTC, Jonathan Levi wrote:
> I would love a more portable solution though.  This should work for now.

How are you building the D code?  It should be possible to build a library (with -lib and/or -shared) that statically includes the runtime and Phobos.

If you want to dynamically link the standard libraries, then you shouldn't need to specify the full path (just "phobos2" and "druntime") as long as they're installed in one of the system's library search paths (see /etc/ld.so.conf on GNU/Linux).

On 2019-09-03 03:45, Jonathan Levi wrote:

> It looks like what needs to be found are "libphobos2" and "libdruntime".  They can be found where ever your system puts lib files.  Windows (as far as I know) does not have a joined place for lib files so you need to look where dmd/ldc/etc installed itself.  On Linux lib files are generally put in `/usr/lib`. Ideally the hunting for lib files should be left to a build tool in order to be system agnostic.  In Cabal (Haskell's build tool) add "druntime" and "phobos2" to `extra-libraries`.

This depends on how the compiler is installed. There are several installers that do not put the libraries in `/usr/lib`. BTW, that directory doesn't exist by default anymore on macOS, even if Xcode and the command line tools are installed.

-- 
/Jacob Carlborg

On 2019-09-03 10:43, Jacob Carlborg wrote:

> This depends on how the compiler is installed. There are several installers that do not put the libraries in `/usr/lib`. BTW, that directory doesn't exist by default anymore on macOS, even if Xcode and the command line tools are installed.

My bad. "/usr/lib" exists, it's "/usr/include" that usually doesn't exist.

-- 
/Jacob Carlborg