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