Am Mon, 01 Oct 2012 15:11:49 +0200
schrieb Jacob Carlborg <doob@me.com>:

> On 2012-10-01 12:42, Johannes Pfau wrote:
> 
> > There are some reasons for dynamic libraries linked at compile time, one is that we have to start somewhere and they are required for plugins / dynamically loaded libraries as well ;-)
> >
> > So I started a small test suite for GDC (could be adapted to other compilers). It currently only tests compile time linking of dynamic libraries, but adjusting the test to use runtime loading should be easy. But it's pointless as long as we have no runtime support. https://github.com/jpf91/dso-test
> 
> Isn't "dmain2" used when building shared libraries using GDC? That's where the implementation of "rt_init" is located.
> 

the problem is that we don't want the C main function in a shared libgdruntime.so, because you might want to use libgdruntime.so in a C/C++ app which has it's own main function.

So we currently don't link in dmain2.o into the shared library and it
must be included manually when linking an application.
(But dmain2 also contains some stuff that really should be in
libdruntime.so, so this source file should probably be split up at some
time.)

On 1 October 2012 16:06, Johannes Pfau <nospam@example.com> wrote:
> Am Mon, 01 Oct 2012 15:11:49 +0200
> schrieb Jacob Carlborg <doob@me.com>:
>
>> On 2012-10-01 12:42, Johannes Pfau wrote:
>>
>> > There are some reasons for dynamic libraries linked at compile time, one is that we have to start somewhere and they are required for plugins / dynamically loaded libraries as well ;-)
>> >
>> > So I started a small test suite for GDC (could be adapted to other compilers). It currently only tests compile time linking of dynamic libraries, but adjusting the test to use runtime loading should be easy. But it's pointless as long as we have no runtime support. https://github.com/jpf91/dso-test
>>
>> Isn't "dmain2" used when building shared libraries using GDC? That's where the implementation of "rt_init" is located.
>>
>
> the problem is that we don't want the C main function in a shared libgdruntime.so, because you might want to use libgdruntime.so in a C/C++ app which has it's own main function.
>

That is at least one of the theories behind it anyway. :-)

The more I think about it, the less I think I would want a C++ app to link against a D shared library though.

With C, there will need to be defined a common interface header - similar to what used to be mars.h in rt/ but also contain some useful runtime functions.


Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 2012-10-01 17:03, Johannes Pfau wrote:

> I tested two different configurations:
>
> druntime and phobos are shared libraries as well (this is the correct
> solution, it's mostly working except for the GC issues)

I agree.

> druntime and phobos static linking: phobos and druntime are statically
> linked into the app, libdso.so is not linked against druntime/phobos at
> all. (this is a hack to get better test results: With a shared
> druntime, you can't call GC.collect twice, because the first call
> frees important objects in druntime and then the second call segfaults)

Ok.

-- 
/Jacob Carlborg

On 2012-10-01 17:06, Johannes Pfau wrote:

> the problem is that we don't want the C main function in a shared
> libgdruntime.so, because you might want to use libgdruntime.so in a
> C/C++ app which has it's own main function.
>
> So we currently don't link in dmain2.o into the shared library and it
> must be included manually when linking an application.
> (But dmain2 also contains some stuff that really should be in
> libdruntime.so, so this source file should probably be split up at some
> time.)

I'm not sure if I follow this correctly or not, but why is this needed to be handled manually? If you pass "-shared" to the compiler just skip linking dmain2.o, otherwise link with it. Would that work?

-- 
/Jacob Carlborg

Am Mon, 01 Oct 2012 19:18:46 +0200
schrieb Jacob Carlborg <doob@me.com>:

> On 2012-10-01 17:06, Johannes Pfau wrote:
> 
> > the problem is that we don't want the C main function in a shared libgdruntime.so, because you might want to use libgdruntime.so in a C/C++ app which has it's own main function.
> >
> > So we currently don't link in dmain2.o into the shared library and
> > it must be included manually when linking an application.
> > (But dmain2 also contains some stuff that really should be in
> > libdruntime.so, so this source file should probably be split up at
> > some time.)
> 
> I'm not sure if I follow this correctly or not, but why is this needed to be handled manually? If you pass "-shared" to the compiler just skip linking dmain2.o, otherwise link with it. Would that work?
> 

Yes something similar would work, it's just not yet implemented.

GDC should detect if we're linking against a shared druntime and then it should automatically add dmain2.o to the linker command.

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

Hello D Experts

I am replying to an old thread since I want to know if and how the situation has improved over the past few months. In particular I want to link and call fairly complex D functions from a C++ application.

I am exclusively using Linux. Can somebody please guide me if I should expect things to work with current DMD master from github?

Regards
- Puneet

On 06/18/2013 10:14 AM, Bottled Gin wrote:
>
>> 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
>>
>
> Hello D Experts
>
> I am replying to an old thread since I want to know if and how the
> situation has improved over the past few months. In particular I want to
> link and call fairly complex D functions from a C++ application.
>
> I am exclusively using Linux. Can somebody please guide me if I should
> expect things to work with current DMD master from github?
>
> Regards
> - Puneet

There's a DConf talk about shared libraries in D.

Perhaps there's useful information there?
http://www.youtube.com/watch?v=i63VeudjZM4

(I'm watching it now so I don't know how detailed it is.)

On Tuesday, 18 June 2013 at 20:23:42 UTC, 1100110 wrote:
> On 06/18/2013 10:14 AM, Bottled Gin wrote:
>>
>>> 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
>>>
>>
>> Hello D Experts
>>
>> I am replying to an old thread since I want to know if and how the
>> situation has improved over the past few months. In particular I want to
>> link and call fairly complex D functions from a C++ application.
>>
>> I am exclusively using Linux. Can somebody please guide me if I should
>> expect things to work with current DMD master from github?
>>
>> Regards
>> - Puneet
>
> There's a DConf talk about shared libraries in D.
>
> Perhaps there's useful information there?
> http://www.youtube.com/watch?v=i63VeudjZM4
>
> (I'm watching it now so I don't know how detailed it is.)

Hello all,

I'm wondering if this has been resolved to date. I get this error on master:

/usr/bin/ld: generated/linux/release/64/libphobos2.so.0.66.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC
generated/linux/release/64/libphobos2.so.0.66.o: could not read symbols: Bad value
collect2: error: ld returned 1 exit status

even though I've built with fPIC:

cc -c  -m64 -fPIC -O3 etc/c/zlib/trees.c -ogenerated/linux/release/64/etc/c/zlib/trees.o
cc -c  -m64 -fPIC -O3 etc/c/zlib/uncompr.c -ogenerated/linux/release/64/etc/c/zlib/uncompr.o
cc -c  -m64 -fPIC -O3 etc/c/zlib/zutil.c -ogenerated/linux/release/64/etc/c/zlib/zutil.o

etc...