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


That's a backend bug though, GDC and LDC shouldn't be affected. But
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
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.


 That's a backend bug though, GDC and LDC shouldn't be affected. But
 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
next 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
prev sibling 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