They both return 4, and both short and int16_t return 2.
Also, I've noticed that if I use a struct (of four ints) instead, the
same thing happens, the parameters are not correct. And yes, of course
they are extern already.
AFAIK 'int' in D is always a 32-bit value. But in C, 'int' could be
64bit on 64bit platforms. You could try printing sizeof(int) in C and
compare that to int.sizeof in D and see if they match. You probably
know this, but make sure your exported D function is annotated with
extern(C).
All right, found something really odd today, might be a bug. If in C I
have this:
int16_t D_getPictureCoordX(int Pool, int Card);
And in D I have this:
short D_getPictureCoordX(int Pool, int Card);
When I call D_getPictureCoord() from C, the parameters are all off, it
seems that it receives eit
Oh, never mind. About sending strings, I got it working, I just had to
create a function like this in D:
immutable(char)* GetString()
{
return StringD.toStringz();
}
As for D not compiling, I had to declare it in D, d'oh :D And that
extern is in the wrong place there.
All right, I solved that part of the problem by creating a linked
list. However, getting the string out of D is still problematic,
namely because toStringz() gives me an immutable char*, and I don't
seem to be able to pass those, since I can't assign those to immutable
variables outside their const
Hmm, if I was to do it from C, I would have to deal with all the
allocation, since I don't know how large the array is going to be when
it's complete, while D doesn't need to know since it uses dynamic
arrays.
Dainius (GreatEmerald) Wrote:
> Well, the situation is like this: D creates a list of names of files
> that should be loaded by C. C then takes the list, uses it to load the
> files, then stores both the pointers to the loaded files and the names
> of the files in an array of structs. Then when C
Dainius (GreatEmerald):
> Well, the situation is like this: D creates a list of names of files
> that should be loaded by C. C then takes the list, uses it to load the
> files, then stores both the pointers to the loaded files and the names
> of the files in an array of structs. Then when C wants
Well, the situation is like this: D creates a list of names of files
that should be loaded by C. C then takes the list, uses it to load the
files, then stores both the pointers to the loaded files and the names
of the files in an array of structs. Then when C wants to access the
files, it asks D ab
Dainius (GreatEmerald):
> OK, now I have a question about passing variables. In D, I have a
> dynamic array of strings and I want C to get that array. Yet C
> supports neither dynamic arrays nor strings. So is there a way to
> accomplish this?
To use a D data structure from C you need first of al
OK, now I have a question about passing variables. In D, I have a
dynamic array of strings and I want C to get that array. Yet C
supports neither dynamic arrays nor strings. So is there a way to
accomplish this?
Oh, I found the problem... It's just me forgetting that my library has
to go before phobos to compile it. So right now it works perfectly!
Thanks!
Hmm... Spent a few hours trying to figure out how to update GCC and
all to conform to the requirements for 2.0.52, and at seems that it
compiles my small test program just fine, but it fails on compiling
the main project for some reason. And the linker outputs
half-scrambled things. Anyway, here's
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 f
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
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
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
extern int ResultD;
int Process(int Value);
int rt_init();
int rt_term();
void LinuxInit();
int main()
{
int num;
rt_init(); //I
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
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 havi
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;
On 2011-02-07 20:07, Steven Schveighoffer wrote:
On Mon, 07 Feb 2011 13:53:14 -0500, spir wrote:
On 02/07/2011 04:32 PM, Steven Schveighoffer wrote:
On Mon, 07 Feb 2011 06:42:46 -0500, spir wrote:
On 02/07/2011 07:53 AM, GreatEmerald wrote:
Hmm, no, it won't work right on Linux for some r
On Mon, 07 Feb 2011 13:53:14 -0500, spir wrote:
On 02/07/2011 04:32 PM, Steven Schveighoffer wrote:
On Mon, 07 Feb 2011 06:42:46 -0500, spir 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-
On 02/07/2011 04:32 PM, Steven Schveighoffer wrote:
On Mon, 07 Feb 2011 06:42:46 -0500, spir 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)
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, t
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
On Mon, 07 Feb 2011 10:28:41 -0500, GreatEmerald 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", Va
On 2/7/11, GreatEmerald 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 06:42:46 -0500, spir 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_finddataFPvZPS2r
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;
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,
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._D2rt4deh21
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+0x
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
Hmm, not being able to use D function kinda defeats the purpose of using it in
the
first place. Ah well, let's see if people know more about this elsewhere.
Anyway, I'm trying to compile this under Linux now. DMD works brilliantly and I
get techborg.a file. I do this (using Debian x64):
$ gcc -m
On 1/19/11, GreatEmerald wrote:
> All right, it worked, when the D side is this:
>
> module techborg;
> 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);
>
All right, it worked, when the D side is this:
module techborg;
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;
}
However, if I wanted to us
Also make sure you use globals properly if you use them (shared,
__gshared, etc.)
On 1/17/11, GreatEmerald wrote:
> Ah, I see, thanks! I'll try that.
>
> While I don't have a problem with using DMC, but others who are willing to
> join my
> project might have one... Right now I'm using MinGW, so it would definitely
> be
> useful to know how to convert the libraries to the forma
Ah, I see, thanks! I'll try that.
While I don't have a problem with using DMC, but others who are willing to join
my
project might have one... Right now I'm using MinGW, so it would definitely be
useful to know how to convert the libraries to the format it understands...
Though
from the looks of
I've just realized I didn't even prototype the function in the C
module. DMC doesn't warn about this, it seems. Not even with the -A
(ANSI C) flag. It won't even warn me when I prototype the function and
pass doubles instead of ints. Maybe I didn't enable all warnings?
(I've used: dmc -wc -v2 -A).
On 01/16/2011 05:04 PM, Ellery Newcomer wrote:
On 01/16/2011 03:34 PM, Andrej Mitrovic wrote:
The problem (on Windows), is that the static lib is in the OMF format,
and modern tools like VC or MinGW won't be able to read those, because
they use COFF instead. So you would have to convert from OMF
On 01/16/2011 03:34 PM, Andrej Mitrovic wrote:
The problem (on Windows), is that the static lib is in the OMF format,
and modern tools like VC or MinGW won't be able to read those, because
they use COFF instead. So you would have to convert from OMF to COFF.
But on Linux I think DMD uses the sta
The problem (on Windows), is that the static lib is in the OMF format,
and modern tools like VC or MinGW won't be able to read those, because
they use COFF instead. So you would have to convert from OMF to COFF.
But on Linux I think DMD uses the standard Linux object file format,
so I don't think
Of course!
dstatic.d:
module dstatic;
extern(C):
int add(int x, int y)
{
return x + y;
}
Then compile with:
dmd -lib dstatic.d
driver.c:
#include "stdio.h"
int main()
{
printf("add(4, 5) = %d", add(4, 5));
}
dmc driver.c dstatic.lib
driver.exe
> add(4, 5) = 9
Is it possible to write a static library in D and then use it in a program
written in C? I've found instructions about using DLLs here on the website,
but there is no mention about using static libraries instead.
Also, is it possible to use the same method on Linux, just with .a files
instead? Or
45 matches
Mail list logo