Bzip2 / name mangling / C libs for kdewin32

[Christian Ehrlicher]

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.

Christian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mail.kde.org/pipermail/kde-windows/attachments/20070411/d7192b74/attachment.pgp