Re: [boost] Newbie Trying to Build Boost Libraries on 64-bit MS WindowsVista

From: Stephen Nuchia (snuchia_at_[hidden])
Date: 2008-07-08 14:56:57

> From: Beverly Pope [mailto:countryone77_at_[hidden]] 
   
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