On 2012-09-27 10:55, Maxim Fomin wrote:

> If it were non-runnable, I wouldn't posted it.

Ok, I see.

> Solution depends on a problem. I understood Andrei's post that he wanted
> a .so file or DLL. I told originally that it is possible to make shared
> libraries on linux. Now I see there is some misunderstanding. Is the
> problem in diving D application on executables and shared libraries or
> making druntime+phobos a shared library or loading a library at runtime?
> A was speaking about the first.

Obviously he wants to use the shared library, otherwise it would be rather useless and pointless.

Last I checked there was a problem with:

* Using a shared library written in D with a D application
* Making druntime and Phobos shared libraries
* Possibly also compiling shared libraries

-- 
/Jacob Carlborg

On Thursday, 27 September 2012 at 09:16:48 UTC, Jacob Carlborg wrote:
> On 2012-09-27 10:55, Maxim Fomin wrote:
>
>> If it were non-runnable, I wouldn't posted it.
>
> Ok, I see.
>
>> Solution depends on a problem. I understood Andrei's post that he wanted
>> a .so file or DLL. I told originally that it is possible to make shared
>> libraries on linux. Now I see there is some misunderstanding. Is the
>> problem in diving D application on executables and shared libraries or
>> making druntime+phobos a shared library or loading a library at runtime?
>> A was speaking about the first.
>
> Obviously he wants to use the shared library, otherwise it would be rather useless and pointless.
>
> Last I checked there was a problem with:
>
> * Using a shared library written in D with a D application
> * Making druntime and Phobos shared libraries
> * Possibly also compiling shared libraries

With DMD 2.060 last two points are possible, only first point (Using a shared ...) I dont try

On Thursday, 27 September 2012 at 08:26:08 UTC, Jacob Carlborg
wrote:
>
> Last time I tried this (on Mac OS X) I got several symbols missing. This was all symbols that are usually pointing to the executable, inserted by the compiler. One of them would be "main" and symbols like these:
>
> https://github.com/D-Programming-Language/druntime/blob/master/src/rt/deh2.d#L27

"_deh_" problem AFAIK arise when non-D and D code is merged and
can be avoided. For example, assume C/C++ application using D
library. This can be done by writing D main function which
forwards call to C/C++ main function which uses D shared library
code. Again, sorry for code post, dpaste isn't working:
---main.cpp---
extern "C" void foo(void);

#include <stdio.h>

class CPP
{
public:
    CPP() { printf("CPP ctor\n"); }
};

CPP cpp;

extern "C" int c_main_func()
{
    printf("C main function reached\n");
    foo();
    // C/C++ application
    return 0;
}
---dmain.d---
import std.stdio;

extern(C) int c_main_func();

static this()
{
    writeln("main module ctor");
}

static ~this()
{
    writeln("main module dtor");
}

int main()
{
    return c_main_func();
}
---test.d---
import std.stdio;

static this()
{
    writeln("lib module ctor");
}

static ~this()
{
    writeln("lib module dtor");
}

extern(C) void foo()
{
    auto a = new A("data");
    writeln("in foo");

}

class A
{
    string x;
    static this() { writeln("static ctor"); }
    static ~this() { writeln("static dtor"); }
    this(string x) { writeln("ctor"); this.x = x; }
    ~this() { writeln("dtor"); writeln(x); }
}
------
# g++ main.cpp -c
# dmd -c dmain.d
# dmd -c test.d -fPIC
# gcc -shared test.o -o libtest.so
# gcc dmain.o main.o -ltest -lphobos2 -lpthread -lrt -L.
-Wl,-rpath=.
# ./a.out
CPP ctor
main module ctor
lib module ctor
static ctor
C main function reached
ctor
in foo
static dtor
lib module dtor
main module dtor
dtor
data
# ldd ./a.out
	linux-vdso.so.1 (0x00007fff4cd55000)
	libtest.so => ./libtest.so (0x00007f970520b000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f9704fd3000)
	librt.so.1 => /lib64/librt.so.1 (0x00007f9704dcb000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f9704a26000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f970540e000)
#

On 9/27/12 2:26 AM, Daniel Kozak wrote:
> Now I try it, and it is not required to build shared variant of druntime
> and phobos, only rebuild it with -fPIC

Could you please send a troika composed of one dynlib, one loader using it, and a makefile that puts the all together?

Thanks much!


Andrei

On Thursday, 27 September 2012 at 08:03:34 UTC, Maxim Fomin wrote:
> On Thursday, 27 September 2012 at 05:52:44 UTC, Jens Mueller
> wrote:
>> Maxim Fomin wrote:
>>> You can build shared libraries on linux by manually compiling object
>>> files and linking them. On windows last time I tries it was not
>>> possible.
>>
>> Can you give detailed steps for doing this on Linux? Because nobody as
>> far as I know has made this work yet?
>>
>> Jens
>
> Dpaste seems not working, so, sorry for code
>[snip]

Hmm, that looks nice, seems that stuff improved from last time I checked.

Gonna test this out today. I have project that would gain from "Hot swapping" of Shared libraries. Temporarily solution I made was just writing plugins in C++.

Btw, sorry for OT.
What exactly doesn't work in Dpaste? It seems to work fine for me(TM).
If those are UI glitches, try pressing F5 2-3 times ;D

On 2012-09-27 12:02, Daniel Kozak wrote:

> With DMD 2.060 last two points are possible, only first point (Using a
> shared ...) I dont try

I really need to try this when I get home.

-- 
/Jacob Carlborg

On Thursday, 27 September 2012 at 13:00:24 UTC, nazriel wrote:
> Btw, sorry for OT.
> What exactly doesn't work in Dpaste? It seems to work fine for me(TM).
> If those are UI glitches, try pressing F5 2-3 times ;D

Dpaste was completely down when I tried to post code. It was in the middle of today.

On 2012-09-27 10:55, Maxim Fomin wrote:
> On Thursday, 27 September 2012 at 08:26:08 UTC, Jacob Carlborg wrote:
>> 1. Does this actually run?
>>
>
> If it were non-runnable, I wouldn't posted it.
>
>> 2. This is statically linked with druntime and Phobos. What happens
>> when you create an executable that links with the D dynamic library?
>
> Solution depends on a problem. I understood Andrei's post that he wanted
> a .so file or DLL. I told originally that it is possible to make shared
> libraries on linux. Now I see there is some misunderstanding. Is the
> problem in diving D application on executables and shared libraries or
> making druntime+phobos a shared library or loading a library at runtime?
> A was speaking about the first.

Actually, I seriously doubt everything is working as expected. For example, what happens when an application loads (via dlopen or similar) a D dynamic library:

* Are exception handlers registered
* Are module infos properly registered
* What happens if I call Object.factory, will that find a class in the dynamic library
* Are GC sections registered
* What happens when the library is unloaded, will all of the above be unregistered and cleaned up

A quick look in rt.minfo in druntime shows the it uses a single array or linked list for all module infos. It expect the module infos to be in just one place, i.e. in the application. There's no handling when a dynamic library is loaded.

Have a look at this:

https://github.com/D-Programming-Language/druntime/blob/master/src/rt/minfo.d#L184

That symbol points to the start of the linked list containing module infos. That's only a single linked list, no handling of module infos from multiple places.

rt.minfo needs to be changed to use an associative array with the keys pointing to images (executables and loaded dynamic libraries) and the values mapped to module infos of the given image. It also needs to intercept when a library is dynamically loaded, extract the module infos and register it with the runtime.

I would think that the same is true for exception handling tables, TLS and GC sections.

-- 
/Jacob Carlborg

On 9/27/12 6:26 AM, Maxim Fomin wrote:
[snip]

Thanks! I adapted your code as follows and it works with 2.058 on Centos.

*** lib.d
import std.stdio;

extern(C) int fun()
{
    writeln(", world!");
    return 42;
}

*** main.d
import std.stdio;

extern(C) int fun();

void main()
{
    write("Hello");
    fun();
}

*** Makefile

PHOBOS_PATH=/path/to/phobos/

main: main.o liblib.so
	gcc main.o -llib -lphobos2 -lpthread -lrt -L. -L${PHOBOS_PATH} -Wl,-rpath=. -o main

liblib.so: lib.d
	dmd -fPIC -c lib.d
	gcc -shared lib.o -o liblib.so

%.o: %.d
	dmd -c $<

clean:
	rm -f main main.o lib.o liblib.so

Building the makefile and running ./main prints the classic message. Thanks all for answering, this will get us going.


Andrei

On 2012-09-27 20:25, Andrei Alexandrescu wrote:
> On 9/27/12 6:26 AM, Maxim Fomin wrote:
> [snip]
>
> Thanks! I adapted your code as follows and it works with 2.058 on Centos.

I seriously doubt that everything is working properly, have a look at my reply to Maxim Fomin: http://forum.dlang.org/thread/k3vfm9$1tq$1@digitalmars.com?page=3#post-k4219f:24uft:241:40digitalmars.com

-- 
/Jacob Carlborg