Opened 12 years ago
Last modified 9 years ago
#4866 new Bugs
Tests don't account for locally-built bzip2 library
Reported by: | Dave Abrahams | Owned by: | Jonathan Turkanis |
---|---|---|---|
Milestone: | To Be Determined | Component: | iostreams |
Version: | Boost 1.44.0 | Severity: | Problem |
Keywords: | Cc: |
Description
I am building the iostreams library with -sBZIP2_SOURCE=c:/work/bzip2-1.0.6
, so the build system creates its own bzip2 library in bin.v2/libs/iostreams/build/bzip2/.../threading-multi/boost_bzip2-vc100-mt-gd-1_44.dll
. However, when I try to run the tests through bjam
from the command prompt, I see the tests fail. So I prepared the same environment used by the tests, and find myself facing a dialog that complains that it can't find LIBBZ2.DLL
. It seems like Boost.Build is confused about the name of the DLL on which it depends.
Attachments (2)
Change History (12)
follow-up: 2 comment:1 by , 12 years ago
comment:2 by , 12 years ago
Replying to vladimir_prus:
What is the exact commands that Boost.Build uses to try running the test that fails?
Please see attached log
comment:3 by , 12 years ago
In your log, I see a single failed target -- which is part of config check and does not affect iostream tests. Am I missing something?
I note that command has: set Path=c:\work\build\boost\bin.v2\libs\iostreams\build\bzip2\msvc-10.0\debug;
so it should catch locally-build zlib library. If you consistently get an error, can you use depends.exe to see what the test executable claims to depend on?
comment:4 by , 12 years ago
I think you're missing my point. The actual DLL built is boost_bzip2-vc100-mt-gd-1_44.dll
but the DLL being sought is LIBBZ2.DLL
. Even if the former *were* in the path, it wouldn't work, right?
comment:5 by , 12 years ago
Oh, this particular error is not likely to be caused by Boost.Build. Looking at your log, the bzip2_test executable is linked against boost_iostreams-vc100-gd-1_44.lib, and is not linked against bzip2 implementation. boost_iostreams-vc100-gd-1_44.dll, in turn, is linked against boost_bzip2-vc100-gd-1_44.lib. So, things look just fine.
There are two reasons why dependency on libbz2 can be added. First, it's via c:\work\bzip2-1.0.6\libbz2.def. Can you check whether that file has anything suspicious, or attach it here? Second possible reason is autolink code in iostreams/detail/config/bzip2.hpp. Can you remove #pragma comment(lib, ...) there and do full rebuild ('bjam -a') and see if that improves things?
comment:6 by , 11 years ago
Hi,
I have encountered the same problem in Boost 1.47.0 and suspect the same problem is still present in Boost 1.48.0. With the help of dumpbin.exe, I have discovered that the import library boost_bzip2-vc100-mt-1_47.lib points to libbz2.dll instead of boost_bzip2-vc100-mt-1_47.dll. Currently, the work-around is to copy boost_bzip2-vc100-mt-1_47.dll to libbz2.dll.
I have tried looking into the JAM files to find out why the import library is pointing to the wrong DLL name to no avail because I'm such a newbie with JAM files. I'm suspecting that the DLL and the import libraries were built using libbz2 as their names and then renamed to the Boost library naming convention thus the reason for the import library to be referring to the wrong DLL name.
Does this make sense?
The other thing that's confusing me is why the ZLIB library that is built together with the BZIP2 library is not exhibiting the same problem. This could disprove my theory about the renaming since the two libraries appear to be built from within the same JAM file.
Kind regards, Leo
comment:7 by , 11 years ago
Hi,
I have just looked into my Boost 1.47.0 build logs and here is some clue as to why the above problem is happening. Below is an extract of the message I found in my Boost 1.47.0 build log:
msvc.link.dll bin.v2\libs\iostreams\build\bzip2\msvc-10.0\release\address-model-32\threading-multi\boost_bzip2-vc100-mt-1_47.dll
c:\bzip2-1.0.6\libbz2.def(2) : warning LNK4017: DESCRIPTION statement not supported for the target platform; ignored Creating library bin.v2\libs\iostreams\build\bzip2\msvc-10.0\release\address-model-32\threading-multi\boost_bzip2-vc100-mt-1_47.lib and object bin.v2\libs\iostreams\build\bzip2\msvc-10.0\release\address-model-32\threading-multi\boost_bzip2-vc100-mt-1_47.exp
boost_bzip2-vc100-mt-1_47.exp : warning LNK4070: /OUT:LIBBZ2.dll directive in .EXP differs from output filename 'bin.v2\libs\iostreams\build\bzip2\msvc-10.0\release\address-model-32\threading-multi\boost_bzip2-vc100-mt-1_47.dll'; ignoring directive
It seems that the problem is due to a conflict in the contents of the BZIP2 .def file and the .exp file being used by the Boost build.
I hope this information helps resolve this issue.
Kind regards,
Leo
comment:8 by , 11 years ago
Hi,
Just confirming that this issue also occurs in Boost 1.48.0.
Kind regards,
Leo
comment:9 by , 9 years ago
FYI, this issue is still occurring in Boost 1.53.0.
Here is an extract of the messages generated by Boost Build that could explain why this issue is occurring:
msvc.link.dll bin.v2\libs\iostreams\build\bzip2\msvc-11.0\release\address-model-32\threading-multi\boost_bzip2-vc110-mt-1_53.dll
c:\bzip2-1.0.6\libbz2.def(2) : warning LNK4017: DESCRIPTION statement not supported for the target platform; ignored
Creating library bin.v2\libs\iostreams\build\bzip2\msvc-11.0\release\address-model-32\threading-multi\boost_bzip2-vc110-mt-1_53.lib and object bin.v2\libs\iostreams\build\bzip2\msvc-11.0\release\address-model-32\threading-multi\boost_bzip2-vc110-mt-1_53.exp
boost_bzip2-vc110-mt-1_53.exp : warning LNK4070: /OUT:LIBBZ2.dll directive in .EXP differs from output filename 'bin.v2\libs\iostreams\build\bzip2\msvc-11.0\release\address-model-32\threading-multi\boost_bzip2-vc110-mt-1_53.dll'; ignoring directive
msvc.manifest.dll bin.v2\libs\iostreams\build\bzip2\msvc-11.0\release\address-model-32\threading-multi\boost_bzip2-vc110-mt-1_53.dll
The explanation of the linker message LNK4070 states that it is recommended to modify the .def file. Are we supposed to follow the recommendation before building Boost?
comment:10 by , 9 years ago
Component: | build → iostreams |
---|---|
Owner: | changed from | to
What is the exact commands that Boost.Build uses to try running the test that fails?