"Tiago Gasiba" <tiago.gasiba@gmail.com> wrote in message news:d8q89d$u0g$1@digitaldaemon.com...
> int main2( void ){
>   int *X, i, n;
>
>   n = func(X);

Looks to me like X is not initialized before it is passed to func(), meaning
that garbage is passed.

Hi *,

Thanks you all for the help.
I have successfully written and tested a D routine running in a C project.
I have written a small tutorial, which you can access through my webpage
http://www.gasiba.de under the link "D". Since I'm not a D-guru (in fact
I'm a complete novice), please feel free to comment on what I have written.

The next question which I would like to ask is, how can I integrate the D
startup code, ie gc_init() and others (from dmain2.d), into the C startup
code just by linkage. I know the entry point to C is the _start() routine
which then calls main(). How can I include some code after the _start(),
but before main() such that I'm not required to explicitly call gc_init()
in my C project?

Thanks,
Tiago

Tiago Gasiba wrote:
> Hi *,
> 
> Thanks you all for the help.
> I have successfully written and tested a D routine running in a C project.
> I have written a small tutorial, which you can access through my webpage
> http://www.gasiba.de under the link "D". Since I'm not a D-guru (in fact
> I'm a complete novice), please feel free to comment on what I have written.
> 
> The next question which I would like to ask is, how can I integrate the D
> startup code, ie gc_init() and others (from dmain2.d), into the C startup
> code just by linkage. I know the entry point to C is the _start() routine
> which then calls main(). How can I include some code after the _start(),
> but before main() such that I'm not required to explicitly call gc_init()
> in my C project?
> 
> Thanks,
> Tiago
> 
If you are making a library (rather than just a .o), there should be a special library init function that automatically gets called upon library load - I'm not sure what this is, but it is standard for all .so files.
If you're just making .o files I don't know - I'd suggest having a single "d_init()" function that gets called.

Brad

Brad Beveridge wrote:

> If you are making a library (rather than just a .o), there should be a
> special library init function that automatically gets called upon
> library load - I'm not sure what this is, but it is standard for all .so
> files.
> If you're just making .o files I don't know - I'd suggest having a
> single "d_init()" function that gets called.
> 
> Brad

Sometimes I confuse the word library with object, i.e. .o files. Sorry.
Yes, for now, I'm only interested in generating .o files from D and linking
them to a C project. What I would like to avoid is to manually call
d_init() in the main() function - this should be done somehow automatically
when linking with the D objects. To avoid linker errors in case I decide to
use several D .o files, the changes would have to be shifted to, say
libphobos; am I right?
A simple solution would be to quit the idea of having main() in C and rename
it to C_main() for example.
Then, a properly designed main() function from D would call C_main().
BUT, this introduces changes to the C project that I'm trying to avoid.

BR,
Tiago

Tiago Gasiba wrote:

> Sometimes I confuse the word library with object, i.e. .o files. Sorry.
> Yes, for now, I'm only interested in generating .o files from D and linking
> them to a C project. What I would like to avoid is to manually call
> d_init() in the main() function - this should be done somehow automatically
> when linking with the D objects. To avoid linker errors in case I decide to
> use several D .o files, the changes would have to be shifted to, say
> libphobos; am I right?
> A simple solution would be to quit the idea of having main() in C and rename
> it to C_main() for example.
> Then, a properly designed main() function from D would call C_main().
> BUT, this introduces changes to the C project that I'm trying to avoid.
> 
> BR,
> Tiago

That is a tough problem I think.  I wonder if something along the lines of the following will work:
1) Create a CPP file that has a static class instance, that classes constructor sets up D
2) Link the CPP .o file and D's .o files to the original C project

I've seen a similar trick when using dlopen to load dynamic libraries. So if the above works & the CPP static instance correctly sets up D, then there must be some special "run me first" function for .o files, which you could then look at and generate in a less convoluted fashion.

Good luck - sounds like you may need it :)

Brad