February 02, 2005 Re: extern(C) and data symbols | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ben Hinkle | "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 Re: extern(C) and data symbols | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | 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 Re: extern(C) and data symbols | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | 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 Re: extern(C) and data symbols | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ben Hinkle | 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
|
Copyright © 1999-2021 by the D Language Foundation