On Tuesday 03 February 2009 03:59, John Harper wrote: > Before I try to reverse engineer completely setup.py, is there > something obvious that needs to be done to get it to use the right tool > chain?
I think it's more complicated than that, though in an ideal world it wouldn't have to be that way. I created some patches for Python 2.4.4 a while ago to make it slightly easier to cross-compile it: http://chaos.troll.no/~dboddie/Python/Greenphone/ There were patches to solve similar issues with the build system floating around in the Python bug tracker. I had intended to help push those along a bit, but lack of time prevented me from doing so. The magic incantation that worked for me was this: export HOST_PLATFORM=i386 export TARGET_TOOLS=$SOME_DIR/gcc-4.1.1-glibc-2.3.6/arm-linux/bin export TARGET_PLATFORM=arm-linux CC=$TARGET_TOOLS/$TARGET_PLATFORM-gcc \ CXX=$TARGET_TOOLS/$TARGET_PLATFORM-g++ \ ./configure --prefix=$TARGETDIR --enable-shared --enable-unicode=ucs4 \ --build=$TARGET_PLATFORM --host=$HOST_PLATFORM where SOME_DIR and TARGETDIR are appropriately set, of course. I did experience issues with some extension modules, though. > More generally, it seems like this would be something that lots of > people would want to do. I'm surprised there isn't support for it built > into the distributed version of Python, without having to hack all the > setup files...? I suppose people don't explicitly configure projects for cross-compilation anymore, especially now that things like Scratchbox are used to fake the build environment: http://www.scratchbox.org/ That might also be worth looking at, but you really have to buy in to its way of working to use it fully, in my experience. David -- http://mail.python.org/mailman/listinfo/python-list
