msvc BZ2_bzCompressInit detecting problem

[Christian Ehrlicher]

Ralf Habacker schrieb:
> 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 your setup was wrong.
> 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.
This is far to much work for a simple C system lib. It's enough to
create *one* shared lib and two import libs (one for mingw & one for
msvc). Debug and Release is really not needed here!
> 
> 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 maybe tue for c++ libs but not needed for C.
> 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 ?
Because it's to much work. And because we should stay in sync with
gnuwin32 as much as needed.
> 
> 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.
No, see private mail.
> 
> 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.
This is just true for C++ libs, debug is not needed unless you pass
FILE* - pointers (and other really specific stuff). And do you really
think someone wants to debug a system lib at all?
> 
> Are there any objectivities against this point of view ?
> 
I wonder why you now moved from the normal way it was done the last
months to another, gnuwin32 incompatible, method.

Christian