On 21 Feb 2012 at 16:46, VáclavSmilauer wrote:
> > 128 *byte* alignment? Wow. No, no compiler will support that legally
> > as it would crap all over your stack frame. I vaguely remember that
> > GCC caps alignment to 40 bytes due to some supported architecture's
> > stack frame being incapable
On 21 Feb 2012 at 16:30, Jonathan WRIGHT wrote:
> Boost python is being compiled in .obj files and then the whole lot is
> linked into a .pyd.
>
> Do you have some unit tests we could use to check our builds for
> problems? I've not understood how the dll linking requirement works.
> Where sho
> 128 *byte* alignment? Wow. No, no compiler will support that legally
> as it would crap all over your stack frame. I vaguely remember that
> GCC caps alignment to 40 bytes due to some supported architecture's
> stack frame being incapable of going higher.
> If you're aligning to 128 bytes the
Boost python is being compiled in .obj files and then the whole lot is
linked into a .pyd.
Do you have some unit tests we could use to check our builds for
problems? I've not understood how the dll linking requirement works.
Where should the dll live and how do you then cope with other people'
On 21 Feb 2012 at 10:39, VáclavSmilauer wrote:
> > Aligning to 128 bits is surely __attribute__((__aligned__(16)))?
>
> Oops, I wrote it wrong in the title, it is 128-bytes aligned, double[16] with
> natural alignment, i.e. __attribute__((aligned(128))).
>
> Thanks for comments, I will try to pu
Are you saying that you're statically linking BPL into your PYD? If
you are, you shouldn't do that. BPL should live in its own DLL,
*especially* when not on Linux/FreeBSD.
Niall
On 21 Feb 2012 at 9:35, Jonathan WRIGHT wrote:
> Many thanks for the quick response. I think I am OK for the runtim
> Aligning to 128 bits is surely __attribute__((__aligned__(16)))?
Oops, I wrote it wrong in the title, it is 128-bytes aligned, double[16] with
natural alignment, i.e. __attribute__((aligned(128))).
Thanks for comments, I will try to put it into the bugtracker.
___
Many thanks for the quick response. I think I am OK for the runtime as I
am using the msvc compiler from the platform SDK. Depends.exe only picks
up MSVCP90.dll and MSVCR90.dll and KERNEL32.dll.
What is unusual in this package is that boost.python is being linked
into the pyd file by adding al
I am using Boost 1.47
I have these class methods:
void Remove(const std::type_info &type);
void Remove(const boost::python::type_info type);
I tried wrapping them both in Boost.Python:
void (Entity::*Remove1)(const std::type_info&) = &Foo::Remove;
void (Entity::*Remove2)(const boost::python::ty
