www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - deh_end

reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
So I'm all trying out this hot new shared switch, and it works just 
dandy for -m32 when d has the main function. But now I want to be able 
to call my shared lib from C.

my little shared lib, tup.d:


import std.stdio;
extern(C) void xyz(int i){
     writeln(i);
}


compiled like so:

dmd -shared -m32 tup.d -oflibtup.so

my little C program, tok.c:

extern void xyz(int);

int main(int argc, char **argv){
     xyz(1);
}


compiled like so:

gcc -m32 tok.c -L. -ltup

Oh no!

./libtup.so: undefined reference to `_deh_beg'
./libtup.so: undefined reference to `_tlsend'
./libtup.so: undefined reference to `_tlsstart'
./libtup.so: undefined reference to `_deh_end'
collect2: ld returned 1 exit status


It seems like I've run into this before with static libs, but I'll ask 
again anyways. What the heck are these symbols for?

looking in druntime, I find

extern (C)
{
     extern __gshared
     {
         void* _deh_beg;
         void* _deh_end;
     }

So I guess I have to put those in tok.c? And then start druntime?

Okay, fine. add

void *_deh_beg;
void *_deh_end;
__thread void *_tlsstart;
__thread void *_tlsend;

to tok.c

Then everything compiles, but a.out segfaults. I guess it didn't start 
druntime on its own.

so add to tup.d

extern 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();
         }
     }

}

then dmd complains about _fini and _init being multiply defined. what to do?
Feb 24 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-02-24 23:37, Ellery Newcomer wrote:

 So I'm all trying out this hot new shared switch, and it works just
 dandy for -m32 when d has the main function. But now I want to be able
 to call my shared lib from C.

 my little shared lib, tup.d:


 import std.stdio;
 extern(C) void xyz(int i){
 writeln(i);
 }


 compiled like so:

 dmd -shared -m32 tup.d -oflibtup.so

 my little C program, tok.c:

 extern void xyz(int);

 int main(int argc, char **argv){
 xyz(1);
 }


 compiled like so:

 gcc -m32 tok.c -L. -ltup

 Oh no!

 ./libtup.so: undefined reference to `_deh_beg'
 ./libtup.so: undefined reference to `_tlsend'
 ./libtup.so: undefined reference to `_tlsstart'
 ./libtup.so: undefined reference to `_deh_end'
 collect2: ld returned 1 exit status


 It seems like I've run into this before with static libs, but I'll ask
 again anyways. What the heck are these symbols for?


_deh_beg and _deh_end is the start and end of the exception handling 
tables. _tlsstart and _tlsend would be the start and end of the TLS 
data. As far as I know druntime has not yet been adapted to handle 
dynamic libraries.

I think there's a pull request that fixes this.

-- 
/Jacob Carlborg
Feb 25 2012
next sibling parent Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 02/25/2012 09:06 AM, Jacob Carlborg wrote:

 _deh_beg and _deh_end is the start and end of the exception handling
 tables. _tlsstart and _tlsend would be the start and end of the TLS
 data. As far as I know druntime has not yet been adapted to handle
 dynamic libraries.

 I think there's a pull request that fixes this.


Guess I'll wait.

Thanks for the info.
Feb 26 2012
prev sibling parent reply "tivadj" <tivadj gmail.com> writes:
Hi all,

Well, the original post was long time ago, but I have a similar 
problem now. I am linking static D library into C++ executable 
and getting linker errors

Phobos64.lib(sections_win64_4f1_4e2.obj) : error LNK2019 : 
unresolved external symbol _deh_beg referenced in function 
_D2rt14sections_win6412SectionGroup8ehTablesMxFNdZAyS2rt15deh_win64_posix9FuncTable
Phobos64.lib(sections_win64_4f1_4e2.obj) : error LNK2019 : 
unresolved external symbol _deh_end referenced in function 
_D2rt14sections_win6412SectionGroup8ehTablesMxFNdZAyS2rt15deh_win64_posix9FuncTable
//PWConnectedComponentsCount.mexw64 : fatal error LNK1120 : 2 
unresolved externals

I wonder if (at least in theory) it supposed to work now?
I have dmd-2.064.2 Windows x64 and linker from VS2013.
Jan 09 2014
parent reply "tivadj" <tivadj gmail.com> writes:
To resolve the problem (unresolved _deh_beg/_deh_end when 
linking), put the 'main' declaration into the D library. As below

void main(string[])
{
}
Jan 10 2014
parent Jacob Carlborg <doob me.com> writes:
On 2014-01-10 12:21, tivadj wrote:

 To resolve the problem (unresolved _deh_beg/_deh_end when linking), put
 the 'main' declaration into the D library. As below

 void main(string[])
 {
 }


You don't need any arguments for the "main" function if you don't need 
them. It's enough with:

void main () { }

-- 
/Jacob Carlborg
Jan 10 2014