All right, found out how to make it compile. There are two ways:

1) Using DMD for the D part, DMC for the C part and combining them. This is the batch file I use for that:

dmd -c -lib dpart.d
dmc cpart.c dpart.lib phobos.lib

2) Using DMD for the D part, DMC for the C part, DMD for combining them again:

dmd -c -lib dpart.d
dmc -c cpart.c
dmd cpart.obj dpart.lib phobos.lib

The first method gives me a "FIXLIB" warning but compiles OK, the second is nicely silent, thus I prefer the second one. Plus it should work in Linux as well. I'm going to try that shortly.

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?

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'"
(read: "D-begin" / "D-end" I guess, looks like Pascal slang ;-) is nicely output by the linker when your "main" module does not have a main(). (There is a similar error when an imported module has a main(), eg for testing, so that the linker finds 2 of them.) Did you change something before compiling under Linux? Or does this pseudo-error happen only under Linux?
Add an empty main() to your top module, and tell us...

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

On 2011-02-07 07:32, GreatEmerald wrote:
> All right, found out how to make it compile. There are two ways:
>
> 1) Using DMD for the D part, DMC for the C part and combining them. This is
> the batch file I use for that:
>
> dmd -c -lib dpart.d
> dmc cpart.c dpart.lib phobos.lib
>
> 2) Using DMD for the D part, DMC for the C part, DMD for combining them again:
>
> dmd -c -lib dpart.d
> dmc -c cpart.c
> dmd cpart.obj dpart.lib phobos.lib
>
> The first method gives me a "FIXLIB" warning but compiles OK, the second is
> nicely silent, thus I prefer the second one. Plus it should work in Linux as
> well. I'm going to try that shortly.

I would recommend always linking with dmd, then you want need to link any D specifics, like phobos.

-- 
/Jacob Carlborg

Everything is right from what I can tell. This is the code I use for the D part:

module dpart;
import std.c.stdio;

extern(C):

    shared int ResultD;

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

And the C part:

#include <stdio.h>
extern int ResultD;
int Process(int Value);

int main()
{
	printf("Sending 3...\n");
	Process(3);
	printf("The result is %d\n", ResultD);
	getchar();
	return 0;
}

This is pretty much the same thing as in the Windows version, just with scanf()
omitted.

Jacob, in Windows I am required to explicitly tell DMD to compile phobos.lib, but not in Linux. Quite odd.

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

-Steve

On 2/7/11, GreatEmerald <pastas4@gmail.com> wrote:
>
>in Windows I am required to explicitly tell DMD to compile
> phobos.lib, but
> not in Linux. Quite odd.
>

Check the sc.ini file in dmd/windows/bin, make sure it has at least
this for the LIB variable:
LIB="%@P%\..\lib";

On Mon, 07 Feb 2011 10:28:41 -0500, GreatEmerald <pastas4@gmail.com> wrote:

> Everything is right from what I can tell. This is the code I use for the D part:
>
> module dpart;
> import std.c.stdio;
>
> extern(C):
>
>     shared int ResultD;
>
>     int Process(int Value)
>     {
>         printf("You have sent the value: %d\n", Value);
>         ResultD = (Value % 5);
>         return ResultD;
>     }
>
> And the C part:
>
> #include <stdio.h>
> extern int ResultD;
> int Process(int Value);
>
> int main()
> {
> 	printf("Sending 3...\n");
> 	Process(3);
> 	printf("The result is %d\n", ResultD);
> 	getchar();
> 	return 0;
> }
>
> This is pretty much the same thing as in the Windows version, just with scanf()
> omitted.
>
> Jacob, in Windows I am required to explicitly tell DMD to compile phobos.lib, but
> not in Linux. Quite odd.

The issue is that you are not calling the D runtime initialization code.  This is required in order to get D working properly.  See the C main function in druntime here:

https://github.com/D-Programming-Language/druntime/blob/master/src/rt/dmain2.d#L335

Basically, you are going to have to duplicate the runtime startup code.  I'm not sure it will work properly.  People typically run main from D and call their C functions from there.  This is also certainly an option.

The errors you are getting are link errors.  I'm guessing that maybe because you aren't calling the d runtime, the linker is opimizing out the deh code early on, but then needs it again later?  Not sure.

-Steve

OK, well this is interesting... I managed to compile it but it's quite odd. In
order to do that, I added a call to main() in my Process() function, and then
added an empty main() in the D part before "extern(C)". It seems that there are no
conflicts, too.

Andrej, that line is there. But it really doesn't matter, it's not like adding one word to the command line is hard.

On 02/07/2011 06:41 PM, GreatEmerald wrote:
> OK, well this is interesting... I managed to compile it but it's quite odd. In
> order to do that, I added a call to main() in my Process() function, and then
> added an empty main() in the D part before "extern(C)". It seems that there are no
> conflicts, too.

That's it, I guess; you always need a main(), even if empty {}, somewhere. I routinely add that in every module (part of my template code), if only for running test code, and comment it out when the module is /actually/ imported. I consider this as a minor design error.

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