export keyword messes up static linking

[Carlos Santander]

torhu escribió:
> I'm porting headers for a C lib do D.  There are a bunch of globals in 
> the C lib.  To get those correctly linked with the D code, I have to 
> declare them 'export extern extern (C)'.
> 
> That works fine for dynamically linking with the C lib, at least with 
> dmd on windows.  The problem is that it won't work if you try to link 
> statically.  The linker accepts it, but at least some of the globals are 
> not linked with the C definitions, they don't contain the correct values.
> 
> And for linking statically using dmd on linux, it just doesn't work. The 
> export symbols get mangled like '_imp__foo', so it won't link.
> 
> Is there any way around this?  I've tried using a .def file, but it 
> doesn't do anything.  This is what I tried:
> 
> EXETYPE NT
> SUBSYSTEM CONSOLE
> 
> IMPORTS
>     cglobals.var
>     cglobals.array
> 
> 
> If that had worked, I wouldn't have had to declare global C variables 
> 'export' in my import modules, so I would have been able to link the 
> same code both statically and dynamically.
> 
> Littering the code with version statements for this seems a bit over the 
> top.  And using the C preprocessor on D code wasn't supposed to be 
> necessary.

Start with something simple. Maybe this will give you some ideas:

$ cat cmod.c
#include <stdio.h>

void foo()
{
         printf("hi from c\n");
}

$ cat dmod.d
extern (C) void foo();

void main()
{
         foo();
}

$ gcc -c cmod.c

$ gdmd dmod cmod.o

$ ./dmod
hi from c

That was using GDC. On Windows (using DMD) you would replace "gcc" with "dmc" 
and "gdmd dmod cmod.o" with "dmd dmod cmod.obj".

If you have a library, put all your declarations in a single .d (or .di) file, 
and use the .lib instead of the .obj. You can check the Bindings project at 
DSource to see how it's done.

-- 
Carlos Santander Bernal