msvc BZ2_bzCompressInit detecting problem

[Ralf Habacker]

Christian Ehrlicher schrieb:
> Ralf Habacker schrieb:
>   
>> Hi,
>>
>> the last bzip2 releases have problems to detect BZ2_bzCompressInit.
>>
>> I've added a testcase which runs well using mingw, but fails with msvc
>> with the following error (The full compile log is added below)
>>
>> CheckFunctionExists.obj : error LNK2019: Verweis auf nicht aufgel”stes
>> externes Symbol "_BZ2_bzCompressInit" in Funktion "_main".
>>
>>
>>
>> While I tracked this problem down and fixed for mingw, I cannot see any
>> error why msvc fails in this area.
>>
>> Is anyone there who can solve this problem ?
>>
>>     
> Who created the bzip2 package? I don't think I created them because I
> never would create bzip2d.lib and I *know* that it worked with the
> package I uploaded. In the current package, all is messed up again!
> bzip2d.lib is also *never* needed...
> If you don't know how to handle name mangling please don't touch the
> import libs!
>   
Christian Ehrlicher schrieb:
> Ralf Habacker schrieb:
>   
>> Hi,
>>
>> the last bzip2 releases have problems to detect BZ2_bzCompressInit.
>>
>> I've added a testcase which runs well using mingw, but fails with msvc
>> with the following error (The full compile log is added below)
>>
>> CheckFunctionExists.obj : error LNK2019: Verweis auf nicht aufgel”stes
>> externes Symbol "_BZ2_bzCompressInit" in Funktion "_main".
>>
>>
>>
>> While I tracked this problem down and fixed for mingw, I cannot see any
>> error why msvc fails in this area.
>>
>> Is anyone there who can solve this problem ?
>>
>>     
> Who created the bzip2 package? I don't think I created them because I
> never would create bzip2d.lib and I *know* that it worked with the
> package I uploaded. In the current package, all is messed up again!
> bzip2d.lib is also *never* needed...
> If you don't know how to handle name mangling please don't touch the
> import libs!
>   
The bzip2 package uploaded before does not work for me neither with 
mingw nor with msvc. BZ2_bzCompressInit wasn't found in both cases.

Then I downloaded the source package which has cmake support, fixed the 
not found issue for mingw by adding the --kill-at linker flag and run.

mkdir bzip2-build
cd bzip2-build
cmake -G "MinGW Makefiles" ..\bzip2 -DCMAKE_BUILD_TYPE=Release
mingw32-make install
cmake -G "MinGW Makefiles" ..\bzip2 -DCMAKE_BUILD_TYPE=Debug
mingw32-make install
cmake -G "NMake Makefiles" ..\bzip2 -DCMAKE_BUILD_TYPE=Release
nmake install
cmake -G "NMake Makefiles" ..\bzip2 -DCMAKE_BUILD_TYPE=Debug
nmake install
kdewin-packager -name bzip2 -version 1.0.4-3 -root c:\Programme\bzip2 
-srcroot ..\bzip2 -complete
Then I got 5 packages

bzip2-1.0.4-3-bin.zip  -> containing release libraries and tools (for 
end user)
bzip2-1.0.4-3-lib.zip   -> containing development header, debug 
libraries and debug/release import libraries  (dor developers)
bzip2-1.0.4-3-doc.zip -> contains package documentation  (mainly for 
developers, also for end users)
bzip2-1.0.4-3-src.zip  -> complete source package to recompile exactly 
the binary packages
bzip2-1.0.4-3.zip        -> contains bin/lib/doc package content for 
single download

For my opinion this standard prodecure ensures to have complete packages 
with all required files for debug and release binaries, which is easy to 
recompile for everybody using the source package which has to be 
complete to generate all above mentioned binary packages.

As far as I can see the general package layout should have 4 types of 
libraries

mingw release
mingw debug
msvc release
msvc debug

This is already available for qt and kdewin32 and other packages. 
Libraries are distingushed by the prefix (mingw='lib' msvc='') and a 
postfix (release='', debug='d')
for example:

mingw release  -> libstreams.dll
msvc release    -> streams.dll

mingw debug -> libstreamsd.dll
msvc debug    -> streamsd.dll

or

mingw release  -> libkdewin32.dll
msvc release    -> kdewin32.dll

mingw debug -> libkdewin32d.dll
msvc debug    -> kdewin32d.dll

CMAKE has build in support for adding the prefix and a specific variable 
to define the debug postfix -> set (CMAKE_DEBUG_POSTFIX "d")

Headers and doc are common for the 4 types

Why should we not use this layout for all packages to make it easier for 
package maintainers ?

Optimizing single package to have only one dll requires additional 
manual attention and work and does not reduce binary package size very 
much, so I doubt that the additional work would be worth.

Additional having all debug libraries in the binary packages makes it 
easier for people to get into the last corner of the code by themself, 
which reduces the requires package support. Addional I remember that 
with msvc mixing release and debug libraries does not work, so we have 
to support debug and release libraries.

Are there any objectivities against this point of view ?

Regards

Ralf