Quote:
Originally Posted by NiLuJe
Cross-compiling Python is a huge PITA. It supposedly got better w/ 3.x, and some of that got backported to Python 2.7.x, but it's either broken, or I'm too stupid to understand how to use that properly, so I'm currently hacking around it.
Cross-compiling Python binary modules is even more fun. (not). |
I am in in total agreement.
Have you been able to get a working python 2.7.10 from your hacking ?
I can get it to compile just fine (see attached script which disables linking of the PYTHON_HOME directory to 64 bit pythons during the build phase for PGEN/python ), but if I compile it without debug info -- running it on the Kobo will get segfaults at random moments; and if I compile in debugging information, the segfaults quit and I get an exception instead whenever I import *any* ibrary whatsoever -- namely:
-----------------------------------------------------------------------
Python 2.7.10 (default, Jun 29 2015, 23:00:31)
[GCC 4.8.1 20130401 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import math
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: /mnt/user/lib/python2.7/lib-dynload/math.so: undefined symbol: Py_InitModule4
[40857 refs]
>>>
-------------------------------------------------------------------------
According to some information floating around on the web, the name of the init module got changed when Python thinks it is compiling for a 64 bit architecture. So, even though it's cross compiling for a 32 bit arm, I am wondering if the make file is getting confused since I'm compiling it on a 64 bit build machine and maybe it's renaming the symbol inappropriately for a 32 bit arm.
I contacted the python_dev mailing list this morning, after being redirected there from the python-help mailing list. But if the bugs have been happening since 2.7.3 according to the gentoo ebuild, I doubt anyone knows how to fix it.
This is how I get it to compile, and although I tried building the HOST_PYTHON and PGEN in 32 bit mode (commented out), it didn't make any difference on my 64 bit linux distro, even with 32 bit multilib installed.
Code:
#!/bin/bash
set -x
# A parser generator and build system version of python are supposed to be
# needed to run parts of the cross compilation; I do see python used in the
# Makefile, but no references to a build version of PGEN are defined,
# so I don't know if PGEN gets used or not in 2.7.10 -- but I build it anyway...
# As this is what receipies on the web say to do...
make distclean
(
#. /etc/profile.d/32dev.sh # setup 32 bit compile flags for slackware 14.1 --- doesn't help, though.
export LIBDIRSUFFIX=""
./configure # --build=x86_64-unknown-linux-gnu --host=i486-unknown-linux-gnu #(uncomment to build 32bit)
make Parser/pgen python
mv python python_for_build
mv Parser/pgen Parser/pgen_for_build
make distclean
)
# fix setup.py to handle installing to the target system's fake install
# directory found on the build system at $DEVICEROOT.
# We want utf-8, unicode terminal handling -- so make sure python compiles
# with ncursesw substituted for curses.
CURSESFLAGS=`pkg-config --cflags ncursesw`
# Configure python to be built
CFLAGS="${CFLAGS} ${CURSESFLAGS} -g3 -ggdb -gdwarf-4" ./configure --host=${CROSSTARGET} --build=i486-unknown-linux-gnu --enable-unicode --enable-shared --with-pydebug --prefix=/mnt/user --disable-ipv6 --without-pymalloc ac_cv_file__dev_ptmx=yes ac_cv_file__dev_ptc=no ac_cv_have_long_long_format=yes PYTHON_FOR_BUILD=${PWD}/python_for_build PGEN_FOR_BUILD=${PWD}/Parser/pgen_for_build
# Fix a bug in the Makefile
# The build version of python, ought not try to actually use the ARM libraries.
sed -i -e 's%\([[:space:]]\)\(PYTHONPATH=$(DESTDIR)$(LIBDEST)\)%\1-\2%' Makefile
echo "background the process now to Fix the makefile manually if you can"
sleep 10
make PYTHON_FOR_BUILD=${PWD}/python_for_build CROSS_COMPILE_TARGET=yes
echo " Waiting to allow you to see error messages before installing "
sleep 10
# Optionally, binary file stripping could be carried out on the python binary
# Don't strip if you are doing debugging of python
# strip --strip-unneeded python
make install DESTDIR=${DEVICEROOT} PYTHON_FOR_BUILD=${PWD}/python_for_build PGEN_FOR_BUILD=${PWD}/Parser/pgen_for_build
And, although it's incomplete -- this gives you an idea of how I use the linaro-gcc compiler from KoboLabs, to do the cross compiling. It's installed to a 8GB partition/thumb and set up to search a ${DEVICEROOT} directory for header files, and libraries, and I compile all the source code from Kobo's github, and install it and all header files into that directory. On the Kobo itself, I use an external SD card, mouting a linux filesystem at /mnt/user -- and that's where I install experimental binaries like python to test them out.
Code:
#!/bin/bash --init-file
# this file is: use_kobo
echo "Starting subshell with KOBO/ARM linaro gcc and Sourcery_G++_Lite in the path"
set -e
path=`whereis -b use_kobo`
name="${path%%:*}"
path="${path##* /}"
path="/${path%%/${name}}"
export SOURCERYDIR=${path}/../CodeSourcery/Sourcery_G++_Lite
export LINARODIR=${path}/../gcc-linaro-arm-linux-gnueabihf-4.8-2013.04-20130417_linux
echo "Adding CodeSourcery eabi and linaro eabihf compiler suites to the path"
export PATH=${SOURCERYDIR}/bin:${LINARODIR}/bin:${PATH}
export KOBOLABS=${path}/../../KoboLabs
export DEVICEROOT=${KOBOLABS}/deviceroot
#export CROSSTARGET="arm-none-linux-gnueabi"
export CROSSTARGET="arm-linux-gnueabihf"
# Build the linux kernel with these variables
export CROSS_COMPILE="arm-none-linux-gnueabi-"
export ARCH="arm"
# Clean out system shell variables that can affect program compilation
unset CC
unset CFLAGS
unset LDFLAGS
unset CPPFLAGS
unset CPP
unset CXX
unset CXXFLAGS
unset CXXCPP
unset C_INCLUDE_PATH
unset CPLUS_INCLUDE_PATH
unset QT4DIR
unset OBJC_INCLUDE_PATH
unset PKG_CONFIG_PATH
unset PKG_CONFIG_LIBDIR
unset PKG_CONFIG_SYSROOT_DIR
mkdir -p /tmp/kobo-gcc-cross
export TMPDIR=/tmp/kobo-gcc-cross
export CPATH=${DEVICEROOT}/usr/include:${DEVICEROOT}/mnt/user/include
export LIBRARY_PATH="${DEVICEROOT}/lib:${DEVICEROOT}/usr/lib":${DEVICEROOT}/mnt/user/lib
export LDFLAGS="-L${DEVICEROOT}/lib -L${DEVICEROOT}/usr/lib -L${DEVICEROOT}/mnt/user/lib"
# Set up PKGCONFIG to prefer programs that were compiled later, over earlier.
export PKG_CONFIG_PATH="${DEVICEROOT}/mnt/user/lib/pkgconfig:${DEVICEROOT}/usr/lib/pkgconfig:${DEVICEROOT}/lib/pkgconfig"
export PKG_CONFIG_LIBDIR="${PKG_CONFIG_PATH}"
export PKG_CONFIG_SYSROOT_DIR="${DEVICEROOT}"
cleanup() {
echo -e '\033]2;Unknown xterm\007'
trap EXIT
exit $1 $2 $3 $4
}
trap cleanup EXIT
echo -e '\033]2;ARM Sourcery_G++_Lite & linaro-gcc for KOBO shell\007'
set +e
set -o vi
Quote:
As for the initial subject, check if there isn't a permanent LD_PRELOAD in place, I can't remember if the Kobos do this, but the Kindles have such a permanent (/etc/ld.so.preload) library injection in place, for the express purpose of enforcing some env vars.
(Such a thing can be easily caught through strace and/or the ld debug vars).
|
MMM.... Good idea. OK.
I'll check into that.