Bzip2 / name mangling / C libs for kdewin32

[Stromek]

On Wed, Apr 11, 2007 at 07:40:51PM +0200, Christian Ehrlicher wrote:
> Hi,
> 
> I think there is an interest what went wrong with the recent bzip2 
> package, so I'll try to explain. Please ask if you don't understand 
> something.
> 
> When you want to export a C function called 'foo', you can decorate it 
> with 'extern __cdecl'. This produces the symbol '_foo'. __cdecl is the 
> default for msvc afaik.
> --> http://msdn2.microsoft.com/en-us/library/zkwh89ks.aspx
> 
> Another way to export a function on win32 is to define it with 'extern 
> __stdcall'. Then the symbol is named '_foo at xx' where xx is the number of 
> arguments * 4
> --> http://msdn2.microsoft.com/en-us/library/zxk0tw93.aspx
> 
> And the last option is to use declspec(dllexport) which produce the 
> symbol '__imp_foo'. dllexport can be combined with the two above. In 
> this case, two symbols are created for the export lib and both point to 
> the same function.
> 
> The problem with bzip2 was, that __stdcall is used and foo at xx is 
> created. The cmake check for a symbol name uses 'extern foo' and 
> therefore the linker is looking for '_foo'.
> --> Because of this, bzlib.h is patched (in the same way gnuwin32 does 
> it to be compatible) -> '_foo' and '__imp_foo' symbols are created and 
> the check works fine.
> 
> Now to the problem with different libs for mingw/msvc/debug/release.
> A C-only lib can be used by mingw & msvc without any problems so there 
> is no need to distinguish between compilers for them. And creating an 
> extra debug lib is also not needed because imo nobody wants to debug a 
> 3rdparty - lib without recompiling it with current sources and the 
> favorite compiler he's using. Using different libs would also mean to 
> change all cmake scripts. And it would add more confusion about the 
> needed libs.

nice explanation here, thnx

-- 
Stromek