Are there any known bugs with the linker map file dmd can generate (windows) ?
I sometimes get lines like the following in the exports section:
 0003:00009E60 D4core7runtime7Runtime10initia 0003:00009E60 D4core7runtime7Runtime10initializeFDFC6object9ThrowableZvZb

Whereas a intact linke should look something like this:
 0003:00009E9C D4core7runtime7Runtime4argsFNdZAAya _D4core7runtime7Runtime4argsFNdZAAya

Also does it use some special encoding? I sometimes get funny stuff like:
 0003:00013D8C D4core10Ùfcounted14__T7RCArrayTaZ€ˆ‹6__ctorMxFKxS€©¶Z€«¬  _D4core10Ùfcounted14__T7RCArrayTaZ€ˆ‹6__ctorMxFKxS€©¶Z€«¬

Any help would be appreciated.

Kind Regards
Benjamin Thaut

Ok I found a bug ticket about this issue:
http://d.puremagic.com/issues/show_bug.cgi?id=6673

Would this be very hard to fix?
I have a working druntime.dll but now that I need to add more exports this bug is a real showstopper.

Kind Regards
Benjamin Thaut

On 29.01.2012 16:55, Benjamin Thaut wrote:
> Also does it use some special encoding? I sometimes get funny stuff like:
> 0003:00013D8C D4core10Ùfcounted14__T7RCArrayTaZ€ˆ‹6__ctorMxFKxS€©¶Z€«¬
> _D4core10Ùfcounted14__T7RCArrayTaZ€ˆ‹6__ctorMxFKxS€©¶Z€«¬

long symbol names (>127 characters) are compressed, you can use core.demangle.decodeDmdString to get the uncompressed symbol.

On 29.01.2012 17:05, Benjamin Thaut wrote:
> Ok I found a bug ticket about this issue:
> http://d.puremagic.com/issues/show_bug.cgi?id=6673
>
> Would this be very hard to fix?
> I have a working druntime.dll but now that I need to add more exports
> this bug is a real showstopper.
>
> Kind Regards
> Benjamin Thaut

Be prepared for more trouble: IIRC the number of exports in the def file, that optlink supports is limited.

I guess you might know, but here are patches to build a phobos.dll, but they are almost 2 years old now: http://d.puremagic.com/issues/show_bug.cgi?id=4071

Am 29.01.2012 18:24, schrieb Rainer Schuetze:
>
>
> On 29.01.2012 17:05, Benjamin Thaut wrote:
>> Ok I found a bug ticket about this issue:
>> http://d.puremagic.com/issues/show_bug.cgi?id=6673
>>
>> Would this be very hard to fix?
>> I have a working druntime.dll but now that I need to add more exports
>> this bug is a real showstopper.
>>
>> Kind Regards
>> Benjamin Thaut
>
> Be prepared for more trouble: IIRC the number of exports in the def
> file, that optlink supports is limited.
>
> I guess you might know, but here are patches to build a phobos.dll, but
> they are almost 2 years old now:
> http://d.puremagic.com/issues/show_bug.cgi?id=4071

I'm not really interrested in a phobos shared lib because I only use 2 modules from phobos (traits, typetuple). I'm currently trying to make a shared library version of druntime so that I can create own shared libraries that all use the same druntime dll. Doing that I hope to bypass all the tls / gc issues, because there is only one instance of druntime. I don't want to dynamically load the dlls I just want to link them into the executables. If I'm not mistaken that would cause all symbols to be already resolved before any D code starts running.

Do you see any problem with this approach?
If optlink only supports a limited number of exports in the def file that is indeed going to be an issue.

Mabye if they get dynamic library support on linux done at some point the situation improves.

Kind Regards
Benjamin Thaut

On 29.01.2012 19:20, Benjamin Thaut wrote:
> Am 29.01.2012 18:24, schrieb Rainer Schuetze:
>>
>> I guess you might know, but here are patches to build a phobos.dll, but
>> they are almost 2 years old now:
>> http://d.puremagic.com/issues/show_bug.cgi?id=4071
>
> I'm not really interrested in a phobos shared lib because I only use 2
> modules from phobos (traits, typetuple). I'm currently trying to make a
> shared library version of druntime so that I can create own shared
> libraries that all use the same druntime dll. Doing that I hope to
> bypass all the tls / gc issues, because there is only one instance of
> druntime. I don't want to dynamically load the dlls I just want to link
> them into the executables. If I'm not mistaken that would cause all
> symbols to be already resolved before any D code starts running.
>
> Do you see any problem with this approach?

Most of the patch deals with druntime issues, sharing the phobos library is just a simple add-on.

Just a few issues I remember:

- the init code needs to be split into one part that the shared dll can do, and one for each client of the dll (e.g. register to get notified in case a thread is created (for static TLS ctors), register memory roots to be scanned by the GC). Some of this has been done in a recent commit.

- it is not obvious whether the client's module_infos should be shared across all clients (my patch does not share these)

- importing data symbols through the import table needs special support in the client dll which dmd does not generate. That's why my patch scans relocations into the import table to change the place of the relocation to the address in the shared dll.

Rainer