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