Re: [GD-General] Sharing DSP between static lib / DLL

[<cas...@ya...>]

Pierre Terdiman wrote:
> Now that I think about it, I might be confused a bit. Here's the thing :
>
> 1) In a standard DLL, if I want to export a function I write something
like
> :
>
> __declspec(dllexport)     int SomeFunction(int some_param);
>
> Then SomeFunction() can be found in the DLL, with a decorated name. Any
> application that wants to use it has to include the header, link with the
> .lib, and the .dll is used at runtime. You can't use GetProcAddress on
> SomeFunction(), unless you use a .def file.

You can't use GetProcAddress unless you know the C++ decorated name of the
function.


> 2) In a standard DLL, if I write this instead :
>
> extern "C" __declspec(dllexport)     int SomeFunction(int some_param);
>
> Then we have the same story, except you can now use GetProcAddress on
> SomeFunction() without a .def file, i.e. the name is not decorated. This
is
> handy in MAX file to get rid of the .def file, for example.

In C the names are not decorated, so you can use it as is.


> 3) Now, in a static library, I don't have any import / export marks. I
just
> have :
>
>     int SomeFunction(int some_param);
>
> If a DLL wraps that library, SomeFunction() doesn't appear in the DLL
(with
> a decorated name or not), so you can't use GetProcAddess() on it, but you
> can still use it in your app (the app beeing otherwise using the wrapping
> DLL).
>
>
> What are .def files useful for, exactly, when not using GetProcAddress() ?

The .def file and __declspec(dllexport) does exactly the same thing. On
mingw the compiler does not understand the __declspec(dllexport) directive,
so it depends on another tool that generates a .def file for it. The result
is the same. The problem is that gcc and vc++ decorate the function names in
a different way, so that tools is not as usefull as I thought.

What I think it could be going on, is that you are building the .lib file as
if it were a dll. The functions preserve the export/import tag in the lib
file. When you build the it as a DLL everything works as expected, and when
using a .lib file, the exported functions are added to the export and import
tables. I assume that the compiler is smart enough to notice that the
function does not need to be imported, like when you use an exported
function within the dll that exports it.

Well, I could be totally wrong, so just take your own conclusions. Hope that
helps.


Ignacio Castaño
cas...@ya...


___________________________________________________
Yahoo! Móviles
Personaliza tu móvil con tu logo y melodía favorito 
en http://moviles.yahoo.es