www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - shared lib

reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
trying to build a .so file (actually, trying to resuscitate pyd) with gdc.

celerid is spitting out

gdc -fPIC -nostartfiles -shared -fdebug {lots of object files plus some
link directives}

which is spitting out

/usr/bin/ld: /usr/lib64/libgphobos2.a(object_.o): relocation
R_X86_64_32S against `_D11TypeInfo_Pv6__initZ' can not be used when
making a shared object; recompile with -fPIC
/usr/lib64/libgphobos2.a: could not read symbols: Bad value

any ideas what might be wrong?
Nov 10 2011
next sibling parent reply Jerry <jlquinn optonline.net> writes:
Ellery Newcomer <ellery-newcomer utulsa.edu> writes:

 trying to build a .so file (actually, trying to resuscitate pyd) with gdc.

 celerid is spitting out

 gdc -fPIC -nostartfiles -shared -fdebug {lots of object files plus some
 link directives}

 which is spitting out

 /usr/bin/ld: /usr/lib64/libgphobos2.a(object_.o): relocation
 R_X86_64_32S against `_D11TypeInfo_Pv6__initZ' can not be used when
 making a shared object; recompile with -fPIC
 /usr/lib64/libgphobos2.a: could not read symbols: Bad value

 any ideas what might be wrong?

Shared libs on linux require things to be compiled with -fPIC so the code can be relocated. The error looks like phobos wasn't build with position-independent code. Beyond that I don't know. Jerry
Nov 14 2011
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-11-14 17:31, Jerry wrote:
 Ellery Newcomer<ellery-newcomer utulsa.edu>  writes:

 trying to build a .so file (actually, trying to resuscitate pyd) with gdc.

 celerid is spitting out

 gdc -fPIC -nostartfiles -shared -fdebug {lots of object files plus some
 link directives}

 which is spitting out

 /usr/bin/ld: /usr/lib64/libgphobos2.a(object_.o): relocation
 R_X86_64_32S against `_D11TypeInfo_Pv6__initZ' can not be used when
 making a shared object; recompile with -fPIC
 /usr/lib64/libgphobos2.a: could not read symbols: Bad value

 any ideas what might be wrong?

Shared libs on linux require things to be compiled with -fPIC so the code can be relocated. The error looks like phobos wasn't build with position-independent code. Beyond that I don't know. Jerry

DMD cannot currently generate correct PIC on linux. -- /Jacob Carlborg
Nov 14 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-11-14 19:54, Johannes Pfau wrote:
 Jacob Carlborg wrote:
 DMD cannot currently generate correct PIC on linux.

some inline asm in phobos also doesn't work in PIC (see https://bitbucket.org/goshawk/gdc/issue/166/add-shared-lib-support).

Yeah, that's right, forgot it was not about DMD. -- /Jacob Carlborg
Nov 14 2011
prev sibling parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 11/14/2011 10:31 AM, Jerry wrote:
 The error looks like phobos wasn't build with
 position-independent code.
 
 Jerry

you know, I think you're right. I even wrote out the names of all those *.a files when I was building a gdc rpm. *slaps head* well, it doesn't matter now. I've gotten ldc to generate shared libs successfully. Now I just need to know how to start up druntime. any ideas?
Nov 14 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-11-14 19:05, Ellery Newcomer wrote:
 On 11/14/2011 10:31 AM, Jerry wrote:
 The error looks like phobos wasn't build with
 position-independent code.

 Jerry

you know, I think you're right. I even wrote out the names of all those *.a files when I was building a gdc rpm. *slaps head* well, it doesn't matter now. I've gotten ldc to generate shared libs successfully. Now I just need to know how to start up druntime. any ideas?

core.runtime.Runtime.initialize Not sure if that will initialize everything properly. Have a look in rt.dmain2.main and make sure you do that same initialize the runtime. It would be better if rt.dmain2.main would call rt.dmain2.rt_init instead of do all the initialize directly in main. -- /Jacob Carlborg
Nov 14 2011
parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 11/15/2011 01:19 AM, Jacob Carlborg wrote:
 On 2011-11-14 19:05, Ellery Newcomer wrote:
 
 core.runtime.Runtime.initialize

cool
 
 Not sure if that will initialize everything properly. Have a look in
 rt.dmain2.main and make sure you do that same initialize the runtime.

yep, found that file yesterday a little after I posted
 
 It would be better if rt.dmain2.main would call rt.dmain2.rt_init
 instead of do all the initialize directly in main.
 

I just call rt_init and rt_term. The one thing I'm wondering about is what happens when I need to load multiple d shared libs (the shallow answer is rt_term crashes, but rt_init doesn't). I assume it would create two instances of the d runtime, which is just lovely from a memory leakage perspective. So my bare bones looks like this just now: extern(C) shared bool _D2rt6dmain212_d_isHaltingOb; alias _D2rt6dmain212_d_isHaltingOb _d_isHalting; extern(C) { void rt_init(); void rt_term(); void _init() { rt_init(); } void _fini() { if(!_d_isHalting){ rt_term(); } } } /* extern(C) */ I suppose the isHalting test should go in a critical section, but otherwise I have working pyd modules! Now if only I could remember why I wanted to use pyd in the first place..
Nov 15 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-11-16 01:27, Ellery Newcomer wrote:
 On 11/15/2011 01:19 AM, Jacob Carlborg wrote:
 On 2011-11-14 19:05, Ellery Newcomer wrote:

 core.runtime.Runtime.initialize

cool
 Not sure if that will initialize everything properly. Have a look in
 rt.dmain2.main and make sure you do that same initialize the runtime.

yep, found that file yesterday a little after I posted
 It would be better if rt.dmain2.main would call rt.dmain2.rt_init
 instead of do all the initialize directly in main.

I just call rt_init and rt_term. The one thing I'm wondering about is what happens when I need to load multiple d shared libs (the shallow answer is rt_term crashes, but rt_init doesn't). I assume it would create two instances of the d runtime, which is just lovely from a memory leakage perspective.

Make sure rt_init and rt_term are only called once. You can take a look how it's done in Tango, I've implemented the support for dynamic libraries for Mac OS X. http://www.dsource.org/projects/tango/browser/trunk/tango/core/rt/compiler/ldc/rt/dmain2.d If you don't want to look at Tango code you can have a look at: http://d.puremagic.com/issues/attachment.cgi?id=607 Look at the diff for src/rt/dylib_fixes.c and src/rt/dmain2.d. The GCC attribute __attribute__((constructor)) and __attribute__((destructor)) can be used to initialize and terminate the runtime, look at the diff for src/rt/dylib_fixes.c
 Now if only I could remember why I wanted to use pyd in the first place..

Haha. -- /Jacob Carlborg
Nov 15 2011
prev sibling next sibling parent Johannes Pfau <spam example.com> writes:
Jacob Carlborg wrote:
On 2011-11-14 17:31, Jerry wrote:
 Ellery Newcomer<ellery-newcomer utulsa.edu>  writes:

 trying to build a .so file (actually, trying to resuscitate pyd)
 with gdc.

 celerid is spitting out

 gdc -fPIC -nostartfiles -shared -fdebug {lots of object files plus
 some link directives}

 which is spitting out

 /usr/bin/ld: /usr/lib64/libgphobos2.a(object_.o): relocation
 R_X86_64_32S against `_D11TypeInfo_Pv6__initZ' can not be used when
 making a shared object; recompile with -fPIC
 /usr/lib64/libgphobos2.a: could not read symbols: Bad value

 any ideas what might be wrong?

Shared libs on linux require things to be compiled with -fPIC so the code can be relocated. The error looks like phobos wasn't build with position-independent code. Beyond that I don't know. Jerry

DMD cannot currently generate correct PIC on linux.

some inline asm in phobos also doesn't work in PIC (see https://bitbucket.org/goshawk/gdc/issue/166/add-shared-lib-support). -- Johannes Pfau
Nov 14 2011
prev sibling parent Jerry <jlquinn optonline.net> writes:
Ellery Newcomer <ellery-newcomer utulsa.edu> writes:

 well, it doesn't matter now. I've gotten ldc to generate shared libs
 successfully. Now I just need to know how to start up druntime.

 any ideas?

I haven't tried LDC, sorry. I'd think you would use it similarly to C++. I.e. link your main program to the shared libs and run it.
Nov 14 2011