February 02, 2005
"Ben Hinkle" <Ben_member@pathlink.com> wrote in message news:ctph9f$1utc$1@digitaldaemon.com...
>
> >1) Few C libraries attempt to use global variables as part of their API. It's also considered bad form to do it. Nevertheless, it does happen.
>
> I just bumped into another situation where I had to link in a translated C header: _init_MyStruct in the data segment. In other words if the C header declares a struct and I put that definition in my D module I need to link
in the
> module since otherwise the linker can't find any initialization values for
the
> struct. Since that stuff isn't part of the C library it has to come from
D.

That should only be necessary if the struct has non-zero initializers.

> So I have to add the struct definitions to the same file that has all the translated macros. It's getting header to read those modules since they
have
> function and variable declarations in one file and data structures and
macros in
> another. Compared to the C header it seems less ideal.

You don't need to put the functions and variables in a separate file. Just the variables.


February 02, 2005
Walter wrote:

>>So in order to have a function to call, I need to implement it in D.
>>And when I do, I get object code for the function wrapper (D) code ?
>>And this code has to be linked in somehow, I used an extra library...
>>
>>Hopefully, the function will be easy to inline in the release version.
> 
> Put the functions that generate code into sdl.d. Put the 'extern'
> declarations in sdlextern.d. In sdl.d, import sdlextern.d, but do not link
> in sdlextern.obj. You can see this at work in std.c.linux.linux.

I'm not sure you follow me here...

I don't have a problem with external data symbols. I can see how that
can be a problem with the surprise that "extern" works differently in
D that what it does in C, but that's not the issue here in this case.

The thing is that there is code generated from the SDL wrapper, in
this case "sdl/video.d". And I am not including that on the compiler
commandline, since I'm only compiling my own program that imports it.

And when I link it, it's missing the macros-now-turned-functions:
> /usr/bin/ld: Undefined symbols:
> _SDL_BlitSurface
> __D3sdl4main19SDL_InitApplicationFAAaZi
> __init_6events9SDL_Event

While I *could* include the D module source code directly,
"sdl/video.d sdl/events.d sdl/main.d", I prefer to compile
those into a library, libSDL_d.a - and then include that.

Either way, the D wrapper needs some extra code that C doesn't,
because C uses the macro preprocessor instead of real functions.
Nothing surprising about that, but it's a (tiny) hurdle to porting.

But usually you can get away with just "extern(C)", const and alias.
And neither of those generate any code, the problem is the macros...
And like I said earlier, in this case it's due to the library design.

--anders
February 02, 2005
In article <ctpnrj$257m$2@digitaldaemon.com>, Walter says...
>
>
>"Ben Hinkle" <Ben_member@pathlink.com> wrote in message news:ctph9f$1utc$1@digitaldaemon.com...
>>
>> >1) Few C libraries attempt to use global variables as part of their API. It's also considered bad form to do it. Nevertheless, it does happen.
>>
>> I just bumped into another situation where I had to link in a translated C header: _init_MyStruct in the data segment. In other words if the C header declares a struct and I put that definition in my D module I need to link
>in the
>> module since otherwise the linker can't find any initialization values for
>the
>> struct. Since that stuff isn't part of the C library it has to come from
>D.
>
>That should only be necessary if the struct has non-zero initializers.

The struct has two pointers. I noticed Anders is also missing his struct initializer __init_6events9SDL_Event. Maybe it's a Linux-only problem since I'm on Linux, too.

>> So I have to add the struct definitions to the same file that has all the translated macros. It's getting header to read those modules since they
>have
>> function and variable declarations in one file and data structures and
>macros in
>> another. Compared to the C header it seems less ideal.
>
>You don't need to put the functions and variables in a separate file. Just the variables.

You're right - it's not as bad as I thought. I now just have one file with the
variables (and don't link it in) and the other file has everything else (and
link it in).


February 02, 2005
Ben Hinkle wrote:

> The struct has two pointers. I noticed Anders is also missing his struct
> initializer __init_6events9SDL_Event. Maybe it's a Linux-only problem since I'm
> on Linux, too.

SDL_Event is a union declaration. No idea why it generates code...

--anders
1 2
Next ›   Last »