April 10, 2012
On Tuesday, 10 April 2012 at 14:21:28 UTC, Ellery Newcomer wrote:
> On 04/10/2012 01:31 AM, Jacob Carlborg wrote:
>>
>> The module info (contains the module constructors) need to be setup
>> differently when linking as a shared library.
>>
>
> The odd thing is, when you skip _init and _fini and just do
>
> rt_init();
> writeln("stuff");
> rt_term();
>
> it doesn't segfault

Yes, I experienced the same.
April 10, 2012
On 04/10/2012 12:21 PM, Jacob Carlborg wrote:
> On 2012-04-10 19:12, Ellery Newcomer wrote:
>
>> they would have to be for writeln to not segfault
>
> Ok, I see.
>

tried using __attribute__((constructor)) instead of _init.

If I'm getting this line to fail in rt.minfo.sortCtorsImpl:

                    /* Internal runtime error, dependency on an uninitialized
                     * module outside of the current module group.
                     */
                    (stackidx < modules.length) || assert(0);

would that be the problem you were referring to above?
April 10, 2012
On 2012-04-10 21:28, Ellery Newcomer wrote:

> tried using __attribute__((constructor)) instead of _init.
>
> If I'm getting this line to fail in rt.minfo.sortCtorsImpl:
>
> /* Internal runtime error, dependency on an uninitialized
> * module outside of the current module group.
> */
> (stackidx < modules.length) || assert(0);
>
> would that be the problem you were referring to above?

Might be. It was a while since I last tried to build shared libraries with D. It was before the minfo module was created.

-- 
/Jacob Carlborg
April 10, 2012
On Tuesday, 10 April 2012 at 20:02:16 UTC, Jacob Carlborg wrote:
> On 2012-04-10 21:28, Ellery Newcomer wrote:
>
>> tried using __attribute__((constructor)) instead of _init.
>>
>> If I'm getting this line to fail in rt.minfo.sortCtorsImpl:
>>
>> /* Internal runtime error, dependency on an uninitialized
>> * module outside of the current module group.
>> */
>> (stackidx < modules.length) || assert(0);
>>
>> would that be the problem you were referring to above?
>
> Might be. It was a while since I last tried to build shared libraries with D. It was before the minfo module was created.

This might be related: https://github.com/D-Programming-Language/druntime/pull/114
April 11, 2012
On 2012-04-10 22:10, "Timo Westkämper" <timo.westkamper@gmail.com>" wrote:

> This might be related:
> https://github.com/D-Programming-Language/druntime/pull/114

I think something like this needs to be added to have shared libraries properly work:

https://github.com/dawgfoto/druntime/blob/SharedRuntime/src/rt/dso.d

-- 
/Jacob Carlborg
April 14, 2012
> With gdc I get different errors, but it seems even more difficult to get it working.
>
> Does anyone know what is missing to get proper shared library support working on Linux?
>

Most prerequisites are merged now but there are still some smaller things I need to do.

https://github.com/dawgfoto/dmd/tree/SharedRuntime
 - split off EH changes (github.com/D-Programming-Language/dmd/pull/821)

https://github.com/dawgfoto/druntime/tree/SharedRuntime
 - split off EH changes (github.com/D-Programming-Language/druntime/pull/185)
 - TLS ranges must not be updated in SIGUSR1
 - integrate dylib_fixes.c (weak main, automatic rt_init/rt_term)
 - integrate shared library tests
 - cleaner makefile and unittests

https://github.com/dawgfoto/phobos/tree/SharedRuntime
 - cleaner makefile and unittests

This should be all to support link-time shared libraries.

For runtime loading we'd need:

 - a GC hook to mark/finalize auxiliary memory
 - traversal of DSO dependency DAGs for thread
   local initialization
April 14, 2012
On Saturday, 14 April 2012 at 14:48:47 UTC, Martin Nowak wrote:
>> With gdc I get different errors, but it seems even more difficult to get it working.
>>
>> Does anyone know what is missing to get proper shared library support working on Linux?
>>
>
> Most prerequisites are merged now but there are still some smaller things I need to do.
>
> https://github.com/dawgfoto/dmd/tree/SharedRuntime
>  - split off EH changes (github.com/D-Programming-Language/dmd/pull/821)
>
> https://github.com/dawgfoto/druntime/tree/SharedRuntime
>  - split off EH changes (github.com/D-Programming-Language/druntime/pull/185)
>  - TLS ranges must not be updated in SIGUSR1
>  - integrate dylib_fixes.c (weak main, automatic rt_init/rt_term)
>  - integrate shared library tests
>  - cleaner makefile and unittests
>
> https://github.com/dawgfoto/phobos/tree/SharedRuntime
>  - cleaner makefile and unittests
>
> This should be all to support link-time shared libraries.
>
> For runtime loading we'd need:
>
>  - a GC hook to mark/finalize auxiliary memory
>  - traversal of DSO dependency DAGs for thread
>    local initialization

Ok. Good to know. Is there a ticket where I can follow the progress?

I opened this one, but there might be also another ticket for it : http://d.puremagic.com/issues/show_bug.cgi?id=7870


April 14, 2012
On Sunday, 8 April 2012 at 08:45:46 UTC, Timo Westkämper wrote:
> 	dmd -g -c test.d -fPIC
> 	ld -shared -o libtest.so test.o -lrt -lphobos2 -lpthread
> 	gcc -g main.c -ldl -lpthread

Hmm, wouldn't using DMD directly for the first two compilation steps do the same thing, just faster and simpler? Like this:

    dmd -shared -fPIC test.d

Although in my tests, it always gives me an error like this, no matter which way I try to compile it:

    ld: /usr/lib64/libphobos2.a(lifetime_368_548.o): relocation R_X86_64_32 against `_D15TypeInfo_Shared7__ClassZ' can not be used when making a shared object; recompile with -fPIC
    /usr/lib64/libphobos2.a: could not read symbols: Bad value

Though this is still with DMD v2.058, so perhaps there were some changes with this in the latest version. Or I'm missing something.

By the way, what is the status of D shared libraries on Windows?
1 2 3
Next ›   Last »