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/ _______________________________________________ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
