D hates to be dynamic linked

Jacob Carlborg doob at me.com
Mon Feb 22 12:48:19 PST 2010


On 2010-02-21 19.50, Walter Bright wrote:
> g wrote:
>> (btw linux)
>
> The first step is to make phobos into a shared .so library. Is anyone
> willing to try it and sort out just what the issues are?

I've been trying to do this from time to time on Mac OS X, I've also 
tried with tango. The issues I've encountered are undefined symbols:

Undefined symbols:
   "__deh_beg", referenced from:
       __deh_beg$non_lazy_ptr in deh2.o
   "__deh_end", referenced from:
       __deh_end$non_lazy_ptr in deh2.o
   "__Dmain", referenced from:
       _main in dmain2.o
       _main in dmain2.o
   "__minfo_beg", referenced from:
       __minfo_beg$non_lazy_ptr in moduleinit.o
   "__minfo_end", referenced from:
       __minfo_end$non_lazy_ptr in moduleinit.o

GDC doesn't have this problem. This is how GDC solves some of the above 
undefined symbols:

__Dmain:
GDC doesn't have the C and D main functions in dmain2.d, instead it has 
another file with the main functions that should not be linked if you 
build it as a dynamic/shared library. I tried to do this with tango and 
dmd but then when I built a executable I got undefined symbol on the C 
main function.

__minfo_beg and __minfo_end:
Neither GDC or LDC have these. I don't remember how they handle this but 
it can probably be solved using the function "getsegbyname" or any of 
the similar functions that exist. For this I would need more precise 
information in which segment and section they are located.

__deh_beg and __deh_end:
Both GDC and LDC uses a different exception handling implementation than 
dmd and don't have these. I have no idea what to do about these.


/Jacob Carlborg



More information about the Digitalmars-d mailing list