Bzip2 / name mangling / C libs for kdewin32

[Christian Ehrlicher]

Ralf Habacker schrieb:
> 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.
> 
The file handle (from posix layer) is really a problem here, but passing 
a file handle should be avoided at all. The only place where a file 
handle is passed to another lib is kdewin32 - but this s a c++ lib (and 
not in win32libs).
The debug/release problem is more a c++ & static lib problem and does 
not apply to pure C libs.
> BTW: Thanks for this clarification.
> 
> Ralf
> 
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/20070412/47cf56e6/attachment.pgp