[C++-sig] Python.Boost + Python2.7 + VS2008 issues

[Niall Douglas]

On 19 Apr 2012 at 16:30, JS Unkn0wn wrote:

> Yes, my current problem is embedding on Windows, but my requirements
> are the same as compiling to the embedded system, as the primary
> target is with the Arm processor + proprietary OS. The Windows
> compilation is just a temporary set up until my kit arrives. So I have
> planned for the Windows build to work with the same limitations that I
> would be subjected to with the hardware.

Sure I get all this. However, from our list's perspective, all the 
embedded processor stuff is a completely separate issue that isn't 
important here.

> Until I receive my hardware development kit I am working with a
> Windows substitute environment that provides an OpenGL interface that
> emulates the Pica200 GPU. Though I'm only mentioning that to explain
> why I have to statically link against Python and Boost.Python and have
> no other option.

It's okay, just say you want to statically link everything. No other 
explanation needed unless it may cause the bug.

> I have already achieved my goal of statically linking Boost.Python and
> Python (or at least it appears to). My goal right now is to
> successfully compile and run
> "%BOOST_DIR%\libs\python\example\quickstart", as I really like to have
> all of my tools in order and I would not be comfortable knowing that I
> cannot successfully operate my tool.

Firstly, the MSVC toolset is VERY different to the GCC toolset. 
You'll find static linking harder on MSVC in general. Secondly, just 
because you get it working on MSVC has little to no bearing on 
whether it will work on GCC. Thirdly, you are almost certainly 
cross-compiling given that target CPU, so just because it works on 
GCC or MSVC has not much relevance to whether it will work 
cross-compiled. This is because your target system probably is a 
partial native POSIX implementation with all sorts of non-POSIX 
oddities, whereas GCC emulates a POSIX environment on Windows and 
MSVC isn't POSIX at all.

On that basis, I'd strongly suggest you forget about trying this on 
Windows. Try it on Linux or BSD instead using GCC. They're both 
native POSIX, and if it works there you have some chance it might 
work on your target board.

Even better, once you have it working on native Linux or BSD, try 
cross compiling to ARM and firing it off to an emulated ARM. Or, if 
you can afford it, simply buy an ARM computer outright, install 
Debian squeeze and work on that.


Now past all of the above of using the right tool for the job, 
probably your errors come from failure to find libraries because the 
search paths are screwed up. Try looking into PYTHONPATH or 
overriding sys.path in python. If you have no DLL/SO support, python 
probably has an __import__ override which is linking in static 
libraries by poking them in as an import emulation. That import 
override probably isn't very intelligent, and may be getting 
confused.

I don't think BPL is even ZIP archive aware/aware of packages and the 
package management runtime? That I'm not sure on. If it isn't, and I 
suspect it isn't given BPL's age, BPL could well be making an 
assumption that module loading always comes from the filing system. 
Food for thought anyway.

Niall

-- 
Technology & Consulting Services - ned Productions Limited.
http://www.nedproductions.biz/. VAT reg: IE 9708311Q.
Work Portfolio: http://careers.stackoverflow.com/nialldouglas/