On 02/07/2011 04:32 PM, Steven Schveighoffer wrote:
> On Mon, 07 Feb 2011 06:42:46 -0500, spir <denis.spir@gmail.com> wrote:
>
>> On 02/07/2011 07:53 AM, GreatEmerald wrote:
>>> Hmm, no, it won't work right on Linux for some reason. This is the output:
>>>
>>> /usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../libphobos2.a(deh2_4e7_525.o): In
>>> function `_D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable':
>>> src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0x4):
>>>
>>> undefined reference to `_deh_beg'
>>> src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0xc):
>>>
>>> undefined reference to `_deh_beg'
>>> src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0x13):
>>>
>>> undefined reference to `_deh_end'
>>> src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0x37):
>>>
>>> undefined reference to `_deh_end'
>>> collect2: ld returned 1 exit status
>>> --- errorlevel 1
>>>
>>> The shell script I'm using to compile it is:
>>>
>>> #!/bin/sh
>>> dmd -m32 -c -lib dpart.d
>>> gcc -m32 -c cpart.c
>>> dmd -m32 cpart.o dpart.a /usr/lib/libphobos2.a
>>>
>>> (Although it appears that you don't need to explicitly link with libphobos2, it
>>> does it automatically... and fails with the above error.) Any ideas about
>>> what the
>>> error means?
>>
>> Take my words with much doubt, I've few exp in that.
>> Are you sure you did use same source under both OSes?
>> "undefined reference to `_deh_end' / `_deh_beg'"
>
> deh == d exception handling (or handler, not sure) ;)
>
> Looks like the module that's failing to link is rt.deh

Are you sure of that? I get exactly the same kind of linker error when forgetting a fake main(){} (whatver the number of modules). Eg:
	...
	src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0xc): undefined reference to `_deh_beg'
	src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0x13): undefined reference to `_deh_end'
	...
repeted n times.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

On Mon, 07 Feb 2011 13:53:14 -0500, spir <denis.spir@gmail.com> wrote:

> On 02/07/2011 04:32 PM, Steven Schveighoffer wrote:
>> On Mon, 07 Feb 2011 06:42:46 -0500, spir <denis.spir@gmail.com> wrote:
>>
>>> On 02/07/2011 07:53 AM, GreatEmerald wrote:
>>>> Hmm, no, it won't work right on Linux for some reason. This is the output:
>>>>
>>>> /usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../libphobos2.a(deh2_4e7_525.o): In
>>>> function `_D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable':
>>>> src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0x4):
>>>>
>>>> undefined reference to `_deh_beg'
>>>> src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0xc):
>>>>
>>>> undefined reference to `_deh_beg'
>>>> src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0x13):
>>>>
>>>> undefined reference to `_deh_end'
>>>> src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0x37):
>>>>
>>>> undefined reference to `_deh_end'
>>>> collect2: ld returned 1 exit status
>>>> --- errorlevel 1
>>>>
>>>> The shell script I'm using to compile it is:
>>>>
>>>> #!/bin/sh
>>>> dmd -m32 -c -lib dpart.d
>>>> gcc -m32 -c cpart.c
>>>> dmd -m32 cpart.o dpart.a /usr/lib/libphobos2.a
>>>>
>>>> (Although it appears that you don't need to explicitly link with libphobos2, it
>>>> does it automatically... and fails with the above error.) Any ideas about
>>>> what the
>>>> error means?
>>>
>>> Take my words with much doubt, I've few exp in that.
>>> Are you sure you did use same source under both OSes?
>>> "undefined reference to `_deh_end' / `_deh_beg'"
>>
>> deh == d exception handling (or handler, not sure) ;)
>>
>> Looks like the module that's failing to link is rt.deh
>
> Are you sure of that? I get exactly the same kind of linker error when forgetting a fake main(){} (whatver the number of modules). Eg:
> 	...
> 	src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0xc): undefined reference to `_deh_beg'
> 	src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0x13): undefined reference to `_deh_end'
> 	...
> repeted n times.

Hm... it looks like _deh_beg and _deh_end is something defined by the compiler?  It's used in deh2.d but not defined anywhere in druntime.

I'm pretty sure deh stands for d exception handler.

-Steve

On 2011-02-07 20:07, Steven Schveighoffer wrote:
> On Mon, 07 Feb 2011 13:53:14 -0500, spir <denis.spir@gmail.com> wrote:
>
>> On 02/07/2011 04:32 PM, Steven Schveighoffer wrote:
>>> On Mon, 07 Feb 2011 06:42:46 -0500, spir <denis.spir@gmail.com> wrote:
>>>
>>>> On 02/07/2011 07:53 AM, GreatEmerald wrote:
>>>>> Hmm, no, it won't work right on Linux for some reason. This is the
>>>>> output:
>>>>>
>>>>> /usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../libphobos2.a(deh2_4e7_525.o):
>>>>> In
>>>>> function `_D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable':
>>>>> src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0x4):
>>>>>
>>>>>
>>>>> undefined reference to `_deh_beg'
>>>>> src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0xc):
>>>>>
>>>>>
>>>>> undefined reference to `_deh_beg'
>>>>> src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0x13):
>>>>>
>>>>>
>>>>> undefined reference to `_deh_end'
>>>>> src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0x37):
>>>>>
>>>>>
>>>>> undefined reference to `_deh_end'
>>>>> collect2: ld returned 1 exit status
>>>>> --- errorlevel 1
>>>>>
>>>>> The shell script I'm using to compile it is:
>>>>>
>>>>> #!/bin/sh
>>>>> dmd -m32 -c -lib dpart.d
>>>>> gcc -m32 -c cpart.c
>>>>> dmd -m32 cpart.o dpart.a /usr/lib/libphobos2.a
>>>>>
>>>>> (Although it appears that you don't need to explicitly link with
>>>>> libphobos2, it
>>>>> does it automatically... and fails with the above error.) Any ideas
>>>>> about
>>>>> what the
>>>>> error means?
>>>>
>>>> Take my words with much doubt, I've few exp in that.
>>>> Are you sure you did use same source under both OSes?
>>>> "undefined reference to `_deh_end' / `_deh_beg'"
>>>
>>> deh == d exception handling (or handler, not sure) ;)
>>>
>>> Looks like the module that's failing to link is rt.deh
>>
>> Are you sure of that? I get exactly the same kind of linker error when
>> forgetting a fake main(){} (whatver the number of modules). Eg:
>> ...
>> src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0xc):
>> undefined reference to `_deh_beg'
>> src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0x13):
>> undefined reference to `_deh_end'
>> ...
>> repeted n times.
>
> Hm... it looks like _deh_beg and _deh_end is something defined by the
> compiler? It's used in deh2.d but not defined anywhere in druntime.
>
> I'm pretty sure deh stands for d exception handler.
>
> -Steve

The compiler puts this in the binary.

-- 
/Jacob Carlborg

Now I'm trying to do something more complicated, and it seems that while importing works (it compiles and links fine), actually using the imported things or pretty much anything that D offers makes the program crash. For instance, in the D part:

-------------------
module dpart;
import std.stdio;

version(linux)
{
    int main()
    {
        return 0;
    }
}

extern(C):
shared int ResultD;

int Process(int Value)
{
    writeln("hai"); //<- Hangs here
    printf("You have sent the value %d to the D library.\n", Value);
    ResultD = (Value % 5);
    string a; //Doesn't hang
    a = "10";//Doesn't hang
    printf("String %s", a); //<- Hangs here
    return ResultD;
}
-------------------

There is no readable error, just your ordinary program crash "report this to Microsoft"... Any idea why it's like that?

I've tried compiling the same on Linux and the program still crashes (with segmentation fault there). No error message or anything. And it doesn't matter if I compile the thing from .obj or from .lib files, I still get the same crashes. So it's a real showtopper for me, since what's the use of having static libraries that compile successfully yet crash every time you attempt to use them?..

Anyone have any ideas about what's happening? Or should I just go ahead and submit this to the bug tracker?

On 3/22/2011 6:46 PM, Dainius (GreatEmerald) wrote:
> I've tried compiling the same on Linux and the program still crashes
> (with segmentation fault there). No error message or anything. And it
> doesn't matter if I compile the thing from .obj or from .lib files, I
> still get the same crashes. So it's a real showtopper for me, since
> what's the use of having static libraries that compile successfully
> yet crash every time you attempt to use them?..
>
> Anyone have any ideas about what's happening? Or should I just go
> ahead and submit this to the bug tracker?

The D runtime needs to be initialized.  Call rt_init before using your library and rt_term when your done with it.

The D runtime replaces main with initialization code and renames the programs main to _Dmain.

extern (C) bool  rt_init( void delegate( Exception ) dg = null );
extern (C) bool  rt_term( void delegate( Exception ) dg = null );

Ooh, thanks, it works! Though linking in Linux is still quite odd. So the final code for my test program is this:

==== cpart.c ====
#include <stdio.h>

extern int ResultD;

int Process(int Value);
int rt_init();
int rt_term();
void LinuxInit();

int main()
{
	int num;

	rt_init(); //Init D library
	LinuxInit(); //Code for linking in Linux

	printf("Enter a number\n");
	scanf("%d", &num);
	Process(num);
	printf("The result is %d\n", ResultD);
	getchar();

	rt_term(); //Terminate D library
}

==== dpart.d ====
module dpart;
import std.stdio;

version(linux)
	int main() { return 0; }
extern (C) bool  rt_init( void delegate( Exception ) dg = null );
extern (C) bool  rt_term( void delegate( Exception ) dg = null );

extern(C):
	shared int ResultD;

	int Process(int Value)
	{
		writeln("You have sent the value: ", Value);
		ResultD = (Value % 5);
		return ResultD;
	}

	void LinuxInit()
	{
		version(linux)
			main();
	}

==== commands to compile ====
On Linux:
dmd -m32 -c -lib dpart.d
gcc -m32 -c cpart.c
dmd -m32 cpart.o dpart.a /usr/lib/libphobos2.a

On Windows:
dmd -c -lib dpart.d
dmc -c cpart.c
dmd cpart.obj dpart.lib phobos.lib
Or:
dmd -lib dpart.d
dmc cpart.c dpart.lib C:\D\dmd2\windows\lib\phobos.lib


Though I find it quite odd that I need workarounds like those to compile on Linux, but ah well, it works, at least. Also odd that I can't link using GCC on Linux, it gives me a long list of undefined references (it seems that they are all coming from phobos2, it's here if you wish to look through it: http://pastebin.com/cfyMDzDn ). But once again, at least it works now, so thanks a lot!

On 3/23/2011 3:22 AM, Dainius (GreatEmerald) wrote:
> Though I find it quite odd that I need workarounds like those to
> compile on Linux, but ah well, it works, at least. Also odd that I
> can't link using GCC on Linux, it gives me a long list of undefined
> references (it seems that they are all coming from phobos2, it's here
> if you wish to look through it: http://pastebin.com/cfyMDzDn ). But
> once again, at least it works now, so thanks a lot!

The weird linking with Linux appears to be caused by DMD requiring symbols for thread local storage.  When you declare main, DMD will output those symbols.  I don't know of any other way to get those symbols.

int function() _main = &main; // Makes DMD output the _tls symbols.

Your issue when linking with GCC looks like your missing the pthread library or development files.

gcc cpart.o -o cpart -m32 -Xlinker -L/home/venix/dmd2/linux/bin/../lib32 -Xlinker -L/home/venix/dmd2/linux/bin/../lib64 -Xlinker --no-warn-search-mismatch -Xlinker --export-dynamic -lrt dpart.a -lphobos2 **-lpthread** -lm


Something a little more cosmetic, would be to have the D library call rt_init and rt_term.  That could be automatic with a shared library. With a static library having Library_Init and Library_Quit do it would work.

Ah, including pthread indeed works, but now I've run into another problem related to Linux and architecture. I want to use D for my program that also uses things like SDL and Lua. Earlier when I compiled it, I always did so with 64-bit libraries. But D is so far only in 32-bits, thus when compiling it doesn't accept phobos2. And it also seems that Debian x64 (which I'm using to compile this at the moment) doesn't have 32-bit libs of SDL as well. Plus compiling SDL from source doesn't work either. So how should I proceed with this? Try to get the beta D x64 libraries?

Dainius (GreatEmerald) Wrote:

> Ah, including pthread indeed works, but now I've run into another problem related to Linux and architecture. I want to use D for my program that also uses things like SDL and Lua. Earlier when I compiled it, I always did so with 64-bit libraries. But D is so far only in 32-bits, thus when compiling it doesn't accept phobos2. And it also seems that Debian x64 (which I'm using to compile this at the moment) doesn't have 32-bit libs of SDL as well. Plus compiling SDL from source doesn't work either. So how should I proceed with this? Try to get the beta D x64 libraries?

Assuming it isn't Production Critical, use -m64 flag in DMD. You shouldn't need to "get" the libraries as they come with dmd 2.052. The generated 64 bit might be buggy, but people need to start using it so bugs can be found.