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 ()
To resolve the problem (unresolved _deh_beg/_deh_end when
linking), put the 'main' declaration into the D library. As below
void main(string[])
{
}
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
_D2rt14secti
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 requ
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
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
