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?

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

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

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?

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

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.

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

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

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

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