Bzip2 / name mangling / C libs for kdewin32

Ralf Habacker ralf.habacker at freenet.de
Wed Apr 11 23:37:47 CEST 2007


Christian Ehrlicher schrieb:
> 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.
BTW: ld's auto-import feature uses this symbol to link too
>
> 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'.
This is the reason why adding the Wl,--kill-at makes this dll usable for 
mingw.
>
> --> 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.
What about the msvc file handle problem we encountered in the past ? I 
have learned not to mix debug and release libraries, which requires to 
have release and debug libraries from the bottom to the top libraries.

BTW: Thanks for this clarification.

Ralf




More information about the Kde-windows mailing list