[boost] [iostreams regressions] patches to fix msvc issues

From: David Deakins (ddeakins_at_[hidden])
Date: 2007-03-17 23:51:33

Since it seems like Jonathan Turkanis is not currently available to work 
on maintaining the iostreams library, perhaps someone else with CVS 
write access might apply the attached jamfile patches related to that 
library to RC_1_34_0 (if the release manager approves) and to HEAD.  The 
description of the patches is below.  These, along with the mentioned 
modification to the bzip2 DEF file, should resolve the remaining 
iostreams regressions.

Once the jamfile patches are applied, I'll ping RudbekAssociates to 
delete their current test results, since I believe they run the 
regression tests incrementally and I don't think jamfile changes trigger 
a rebuild.

Thanks,
-Dave

David Deakins wrote:
 > Douglas Gregor wrote:
 >> |iostreams|
 >>   bzip2_test:  msvc-7.1  msvc-8.0
 >>   gzip_test:  msvc-7.1  msvc-8.0
 >>   zlib_test:  msvc-7.1  msvc-8.0
 >>
 >
 > I spent a little bit of time looking into the msvc-7.1 and msvc-8.0
 > regressions for this library.  It looks like the zlib and bzip2
 > libraries used in these tests are being built from source files and it
 > appears that there are some omissions in the iostreams jamfile for
 > properly building them as DLLs in Windows.
 >
 > For zlib, there just needs to be a <link>shared:<define>ZLIB_DLL in
 > its build requirements so that the zlib source files use the
 > __declspec keyword on functions that should be exported.  Without
 > this, no functions are exported and the import library file is not
 > created (thus the link errors).
 >
 > With bzip2, the basic problem is the same but its sources use a .DEF
 > file rather than __declspec (at least in the 1.0.4 sources that I
 > looked at).  Adding <link>shared:<def-file>$(BZIP2_SOURCE)/libbz2.def
 > properly included the DEF file that gives the exports, but revealed
 > another problem.  The DEF file has a 'LIBRARY LIBBZ2' line in it which
 > wants to give the DLL the name libbz2.DLL.  Unfortunately the
 > iostreams jam file typically calls the library something like
 > boost_bzip2-vc80-mt-gd-1_34.DLL and specifies an /OUT directive to the
 > linker to ask for this name.  At least on my machine with VC8, the
 > /OUT directive overrides the LIBRARY rule enough to make the intended
 > boost_bzip2-vc80-mt-gd-1_34.DLL file, but not enough to get this name
 > into the import .LIB file that boost_iostreams links to.  As a result,
 > the iostreams library will compile and link, but will fail trying
 > locate libbz2.DLL (instead of the correct
 > boost_bzip2-vc80-mt-gd-1_34.DLL). The only way I could easily resolve
 > this was to comment out the LIBRARY rule in the libbz2.DEF file in the
 > bzip2 sources like so:
 >
 > ; LIBRARY     LIBBZ2
 >
 > With this change and the patches to the iostreams jamfile, building
 > zlib and bzip2 from sources works correctly and the 3 tests pass.  I
 > attached a patch for jamfile.v2 in libs\iostream\build with my
 > changes.  It might be good to put a note about the bzip2 .DEF file
 > change in the iostreams documentation.
 >
 > Incidently, using <def-file> revealed a small issue in msvc.jam
 > related to DEF file paths that have spaces in them.  The linker
 > command does not put quotes around the DEF path like it does with most
 > of the other parameters, and as a result DEF paths with spaces will
 > cause the link to fail.  I also included a patch to msvc.jam to add
 > quotes around DEF file paths.
 >
 > Thanks,
 > -Dave
 >