Newbie Trying to Build Boost Libraries on 64-bit MS Windows Vista
Hi, I am a complete newbie at boost, who must compile several Boost 1.33.1 Libraries on 64-bit MS Windows Vista, using MS VS2005. I downloaded the 64-bit version of Python (python-2.5.2.amd64.msi) as well as bjam (boost-jam-3.1.16-1-ntx86.zip) and Boost 1.33.1 (boost_1_33_1.zip); I then installed Python and extracted the other two files, placing bjam in the PATH. I tried various things to build the libraries. I finally got some (not all) of them to build by setting MSVCDir, which makes the builds bypass running msvcvars32.bat. I am currently using the following to do the build (I've also tried --toolset=msvc, but that does not do any better): bjam ^ -sTools=8_0-amd64 ^ --prefix=%myBoostDir%\newboost ^ --builddir=%myBoostDir%\newboost ^ --debug-configuration ^ --with-python-root=%myPythonDir% ^ --with-python-version=2.5 ^ --with-pydebug ^ stage ^ > %myBoostDir%\logfile.txt 2>&1 1) I see numerous (21360) warnings like the following -- I don't know whether that is something that can be ignored? D:\work\intersect\boost_1_33_1\boost/config/abi_prefix.hpp(19) : warning C4103: 'd:\work\intersect\boost_1_33_1\boost\config\abi_prefix.hpp' : alignment changed after including header, may be due to missing #pragma pack(pop) 2) When building the libraries, I get the following errors when it tries to build object_protocol.cpp (three times) : vc-C++ d:\work\intersect\boost_1_33_1\newboost\bin\boost\libs\python\build\boost_python.dll\vc-7_1\debug\threading-multi\object_protocol.obj cl : Command line warning D9002 : ignoring unknown option '/Op' object_protocol.cpp D:\work\intersect\boost_1_33_1\libs\python\build\../src/object_protocol.cpp(110) : error C2664: '_PyEval_SliceIndex' : cannot convert parame ter 2 from 'int *' to 'Py_ssize_t *' Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast D:\work\intersect\boost_1_33_1\libs\python\build\../src/object_protocol.cpp(112) : error C2664: '_PyEval_SliceIndex' : cannot convert parame ter 2 from 'int *' to 'Py_ssize_t *' Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast D:\work\intersect\boost_1_33_1\libs\python\build\../src/object_protocol.cpp(137) : error C2664: '_PyEval_SliceIndex' : cannot convert parame ter 2 from 'int *' to 'Py_ssize_t *' Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast D:\work\intersect\boost_1_33_1\libs\python\build\../src/object_protocol.cpp(139) : error C2664: '_PyEval_SliceIndex' : cannot convert parame ter 2 from 'int *' to 'Py_ssize_t *' Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast Do I just need to change the cast or is something else going on? Thanks for your time. Bev
From: Beverly Pope [mailto:countryone77@yahoo.com] I'm not familiar with the -sTools trick, I use --address-model=64 to get 64-bit builds. I've not built with Python so I can't address those errors in detail but I am familiar with the error message from other source codes. 1) I see numerous (21360) warnings like the following -- D:\work\intersect\boost_1_33_1\boost/config/abi_prefix.hpp(19) : warning C4103: >'d:\work\intersect\boost_1_33_1\boost\config\abi_prefix.hpp' : alignment changed after including header, may be due to missing #pragma pack(pop)
The header that is triggering this warning appears to exist for the purpose of changing the pack setting; the warning is correctly describing an intentional situation. I have not investigated but I suspect it is impossible to suppress this warning in the header that is responsible for it without leaving it suppressed outside that header. I recommend ignoring it.
2) When building the libraries, I get the following errors [...] error C2664: '_PyEval_SliceIndex' : cannot convert parameter 2 from 'int *' to 'Py_ssize_t *' Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast [...]
This error message is triggered by a code flaw that is at least potentially very dangerous. It happens when you attempt to cast a function pointer in a way that will result in violations of the calling convention or type safety rules at the call site where the pointer is ultimately used. A reinterpret cast is appropriate only if the pointer will never be used (called) without being cast back to the proper type. There is no way for the compiler, at the pointer assignment, to correct for a mismatch between the declared signature of the function and the signature of the pointer to which you are assigning it. If it were allowed you would have a gaping whole in the language's strong typing paradigm and (yet another) source of very ugly runtime errors. -swn
participants (2)
-
Beverly Pope -
Stephen Nuchia