www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Linking D Runtime

reply Jonathan Levi <catanscout gmail.com> writes:
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!
Aug 23 2019
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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
Aug 23 2019
parent reply Jonathan Levi <catanscout gmail.com> writes:
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
Aug 23 2019
parent sarn <sarn theartofmachinery.com> writes:
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).
Sep 03 2019
prev sibling parent reply Jonathan Levi <catanscout gmail.com> writes:
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`.
Sep 02 2019
parent reply Jacob Carlborg <doob me.com> writes:
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
Sep 03 2019
parent Jacob Carlborg <doob me.com> writes:
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
Sep 03 2019