Kobo's busybox, setuid and mystery about /bin/busybox ?!

[fastrobot]

Hi,

I'm working on a KoboAuraHD and Glo, and of course -- for an embedded system the Kobo uses busybox (likey to save memory) and busybox has some peculiar problems.

I'm needing to create user accounts that are not super-user based, and which allow users to add their own temporary libraries (LD_LIBRARY_PATH), but still allow users to login as superuser, or execute scripts with a command like sudo.

That way games can be installed relatively safely on the kobo.

But -- the kobo won't allow a user to do that. eg: Busybox in the Kobo isn't installed as set user id enabled, and also linux on the Kobo prevents plain scripts from running set user id for good security reasons.

So -- I thought, no problem -- turn on suid root on busybox and configure it like a normal linux system. But then things got *really* strange.....

For a configured busybox doesn't work quite right. eg: And I mean even if /bin/busybox is owned by root, and chmod u+s /bin/busybox is done -- and busybox is configured so that ONLY two busybox applets are allowed to actually run suid, the rest being demoted to normal user -- it STILL doesn't work right.

I did in fact install this config as root:root @ chmod 600 /etc/busybox.config

[SUID]
su = ssx root.root
login = ssx root.root

When a normal user tries to run su or login, busybox is SUPPOED to erase the shell variable LD_LIBRARY_PATH, and several others during busybox operation so that no one can use a hacked library to crack into the system. But busybox has no reason to keep the variables cleared, unless the user is running a dangerous applet as root.

Normally busybox doesn't cause problems...

However, on the Kobo, busybox's modified code strangely doesn't appear smart enough to tell the difference, and it clears the variables regardless of whether they are dangerous or not; and never restores them. ( Hence it causes bugs in innocent programs. )

For example if I want to use a python script requiring an interpreter stored on extenal SD card, which is plugged in temporarily; then there are no superuser priveleges involved, desired, or needed -- and no reason to clear LD_LIBRARY_PATH after busybox terminates suid mode.

Yet, if I export LD_LIRBARY_PATH=/mnt/sd/libs and then create a python script with the standard opening line:

#!/usr/bin/env python 
#test.py -- this file is a script to test python.
print "ran a python 2.7.10 script"

The following happens when you try to use it from a login shell (but not a root shell).

$ EXPORT LD_LIBRARY_PATH=/mnt/sd/libs
$ ./test.py
python: error while loading shared libraries: libpython2.7.so.1.0: cannot open shared object file: No such file or directory
$ python test.py
ran a python 2.7.10 script
[18366 refs]

And the reason is simple, because env is a busybox command -- and it's erasing LD_LIBRARY_PATH and forgetting to restore it once it realizes that 'env' is not supposed to be run as superuser. The erasure never happens except when a busybox command is run.

I tried to download busybox source code to figure out how add code to solve the problem.
But what I'm reading in the source code, and what is happening with busybox don't match.

I even asked George.talusan which version of busybox the Kobo used a while back to make sure I'm not insane, and was told after much ambiguous dialog that the version *in* the repository is in fact up to date. (https://www.mobileread.com/forums/sho...0&postcount=26 )

OK. Fine. So I'll assume the *unlabeled* version of busybox on the kobo git repository is in fact up to date. ( https://github.com/kobolabs/busybox ).

Now, here's where it gets really weird -- see if you can explain what I discovered...:
Busybox runs a subroutine that sanitizes several variables, the routine is the ONLY place that the word LD_LIBRARY_PATH shows up in the whole KoboLabs busybox repository:

https://github.com/kobolabs/busybox/.../libbb/login.c

When I do strings /bin/busybox on the Kobo, sure enough there is only ONE instance of that string in the whole busybox binary. And it should NOT clear shell variables once busybox decides to de-escalate from superuser setuid mode to normal mode... but apparently it still does...

So -- I thought I'd be smart, and used a hex editor to do an experiment -- and searched the /bin/busybox binary, and found the table of strings. I changed only LD_LIBRARY_PATH, to LE_LIBRARY_PATH, and re-saved the binary with the change. I then re-installed it on my kobo as /bin/busybox.
This version of busybox is the one found on my AuraHD after installing KoboUpdate version 3.15.0, which I downloaded manually from MR forums link, and the hexeditor dump of the part I changed follows:

0081660: 484f 4d45 0049 4653 0053 4845 4c4c 004c HOME.IFS.SHELL.L
0081670: 455f 4c49 4252 4152 595f 5041 5448 004c E_LIBRARY_PATH.L
0081680: 445f 5052 454c 4f41 4400 4c44 5f54 5241 D_PRELOAD.LD_TRA
0081690: 4345 5f4c 4f41 4445 445f 4f42 4a45 4354 CE_LOADED_OBJECT

NOTE: You can find the original and edited files, as I got them off my AuraHD in the system.tar.gz archive at the end of this post; along with a utility program called 'system'.

So, in theory -- if /bin/busybox is being run, is must change LE_LIBRARY_PATH, instead of LD_LIBRARY_PATH. But that doesn't happen.... So I began thinking maybe a binary in memory was running and the one on disk was not because it was running when I changed it; so I even rebooted, and it still doesn't work. I checked the md5sum -- and my binary is installed at /bin/busybox.

WTFoobar?!

Busybox magically still erases LD_LIBRARY_PATH and does NOT erase LE_LIBRARY_PATH even though LD_LIBRARY_PATH does not exist anywhere in the binary.. How is this possible ??!

Is the kobo really running /bin/busybox ? or is there a trick making it run a different version of it in spite of the applets specifically pointint at /bin/busybox ?

--------- In the meantime I made a hacky fix that is pretty unix flavor independent -------

I made a second program which allows me to work around the problem and takes up very little memory. Eg: it lets me implement sudo capability on scripts without recompiling busybox, so I can run some of busybox's commands by replacing their soft links in /bin/busybox with a suid script (which doesn't run as suid in linux), that calls a suid program (which does run suid in linux), to decide whether or not to run busybox as a different uid or NOT. This both fixes the problem -- indirectly -- and lets me test busybox out to see if the suid vs. real uid is causing the erasure or not -- result -- the difference in uid and euid is what triggers busybox to erase variables.

Since my only other choice is to recompile busybox so that I have two versions of it, one of which runs as suid -- and one which does not. And this solution wastes less memory.... I thought I would share it as a useful system tool.

I can now make what are reasonably secure one liner scripts like this one for /bin/su:

#!/bin/system \slogin root

The \s makes the script line following it run as superuser, but only if the shell script and the /bin/system program are both owned by root, and only if both are setuid.

Read the comments in the attached source code to how it works, as it's very short -- and I believe it still keeps the system secure. Comments welcome; Busybox no longer needs to be setuid, ever; though I would like to fix it properly.

Now I've tested this weird behavior out, and none of the explanations I come up with make sense.
Any geniuses out there, who can explain how a hex edited version of Busybox is still erasing LD_LIBRARY_PATH? (It's attached so you can check how I edited it.)

ffa324c328fdc4c168433337d4c58c7f busybox.old (Unedited MD5 sum)
0b17487b53dd95a306d834bb8a7ebd79 busybox (Edited busbox's MD5 sum)
e009836ddb97f0f9d01e854f20e2b249 system.tar.gz

[tshering]

Originally Posted by fastrobot

a hex edited version of Busybox is still erasing LD_LIBRARY_PATH

Did you double-check that the edited version is in /bin and did not end up in a different location because of a typo?

[fastrobot]

Originally Posted by tshering

Did you double-check that the edited version is in /bin and did not end up in a different location because of a typo?

Yes, in fact the one I uploaded to MR was actually loaded from /bin/busybox after I telneted into the device after reboot because the original edit on my PC was lost. Whatever I've done wrong, or however busybox it doing what it does -- it's not at all obvious. Though I'm willing to check *any* angle.

I can log in now, here's a capture of a telnet session:

bash-4.2$ !tel
telnet AndrewsKoboHD 2323
Trying 192.168.3.128...
Connected to AndrewsKoboHD.
Escape character is '^]'.
^]
telnet> mode char

~ # stty sane
~ # cd / ; find . -iname busybox
./bin/busybox
~ # md5sum /bin/busybox
0b17487b53dd95a306d834bb8a7ebd79  /bin/busybox
~ # 
~ #

And, if I transfer the file to my PC using my mime transfer shell script -- my main machine's checksum agrees.
Note, my kobo's wireless has opened telnet port 2323, and when the wireless connects it exports a host name I defined in /etc/init.d/rcS -- so my host PC which is running DNSmasq finds my AuraHD by the name (AndrewsKoboHD); I can't get a wrong ip address that way. The same device I do the telnet tests on has to be the one that I receive the file from. There wasn't a GloHD when I made the name up -- so AndrewsKoboHD is actually my AuraHD.

bash-4.2$ export REMOTE="AndrewsKoboHD 2323"
bash-4.2$ mmget.rc /bin/busybox
remote 0b17487b53dd95a306d834bb8a7ebd79 /bin/busybox
local 0b17487b53dd95a306d834bb8a7ebd79 busybox
bash-4.2$

So, there is no other file on the drive named busybox, unless find is malfunctioning. (I have no reason to believe it is broken.)
Of course, there is another copy on the factory restore partition (mmcblk0p2) -- but I don't know how that one could possibly be running as that partition is not mounted; and it's not possible to umount a partition if a binary is being run from it as far as I know.

~ # mount
rootfs on / type rootfs (rw)
/dev/root on / type ext4 (rw,noatime,nodiratime,barrier=1,data=ordered)
none on /proc type proc (rw,relatime)
none on /tmp type tmpfs (rw,relatime,size=16384k)
none on /dev type tmpfs (rw,relatime)
none on /var/lib type tmpfs (rw,relatime,size=16k)
none on /var/log type tmpfs (rw,relatime,size=16k)
none on /var/run type tmpfs (rw,relatime,size=128k)
none on /sys type sysfs (rw,relatime)
/dev/mmcblk0p3 on /mnt/onboard type vfat (rw,noatime,nodiratime,fmask=0022,dmask=0022,codep age=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro)
/dev/mmcblk1p1 on /mnt/sd type vfat (rw,noatime,nodiratime,fmask=0022,dmask=0022,codep age=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro)
/dev/mmcblk1p3 on /mnt/user type ext2 (ro,noatime,nodiratime,barrier=1,data=writeback)
/dev/mmcblk1p2 on /mnt/home type vfat (rw,noatime,nodiratime,uid=500,fmask=0022,dmask=00 22,codepage=cp437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
devpts on /dev/pts type devpts (rw,relatime,mode=600)

Though, now that I'm looking -- it doesn't actually say what device partition is mounted as root.
When I check the Kobo's /proc/mounts, it says that "/dev/root / ext4 ..." is the mounted partition.
But there is no /dev/root found in the udev device directory.

But if I do "mkdir /test ; mount /dev/mmcblk0p1 /test" (The expected root partition)
It says: mount: mounting /dev/mmcblk0p1 on /test failed: Device or resource busy
and it does allow me to "mount /dev/mmcblk0p2 /test" (The expected system restore/reset partition)

So -- root pretty much has to be a mounted version of mmcblk0p1 ...


Question: Can anyone verify that the md5sum I get for the unedited busybox ( ffa324c328fdc4c168433337d4c58c7f ) is the same as is on their device? ESP: for anyone with an AuraHD or a GLO ? According to Talusan, busybox is in the upper git repository directory is up to date -- and since there is only ONE version of it in over a years time; I would expect more device's updates to share a busybox with the same md5sum. eg: I would like to know if that is correct or not.

I'm not sure when talusan says things, that he means by his words the same thing I think he means by his words. It's not that I'm accusing him of anything -- just that I'm new at this. For example, he talked about 100MB being a github limit for binaries, as a justification for why he had to break out busybox in to the upper github directory -- but if you check, he added an KoboGloHD directory (A very large new directory) to the lower directory which supposedly already too big... SO maybe he meant something different than I what I thought he meant.... what does binaries have to do with busybox sourcecode, anyway?

eg: -- I have no idea if I understand talusan correctly when I point to the upper Github directory as being the busybox repository for all devices, but I'd like to find out.

[frostschutz]

It seems to work with the official busybox binary which you can download from the busybox site.

Is there a modification to busybox by Kobo without which the device would not work? Otherwise just replace busybox entire...?

[Lucas Malor]

deleted

[Lucas Malor]

From man env:

PHP Code:

       -i, --ignore-environment
              start with an empty environment 


Maybe busybox on Kobo starts env with -i implicitly?

Anyway, you can install Python on Kobo:

Python 3: https://www.mobileread.com/forums/sho...20#post2885820
Python 2: https://www.mobileread.com/forums/sho...03#post2583203

[fastrobot]

Originally Posted by frostschutz

It seems to work with the official busybox binary which you can download from the busybox site.

Is there a modification to busybox by Kobo without which the device would not work? Otherwise just replace busybox entire...?

I don't know if there is a modification that is critical, or which will become critical in the future.

By comparing the source code tree of busybox for Kobo and others I can find regarding the "sanitizing" of variables; the routine isn't in the same place -- so I know Kobo's source code isn't exactly the same as other releases at least there, and if it's different there -- then how many other changes has Kobo made, and why?

So, there probably is a risk in just replacing busybox.

Thats in part why I asked George Talusan about which version my KoboAuraHD actually was using... because I wanted to make sure I was looking at the right source code to make the decision based on. ( As well as be able to recompile it according to GPL rules, and audit the binary code release to see that it is indeed the same as the source code that it supposedly comes from. )

When I wasn't able to determine for sure what the heck is going on, I made a work around binary rather than change busybox so that I wouldn't trigger any bugs that Nickel or other Kobo programs depend on Kobo's version of busybox to prevent.

GPL software, version 2, and version 3, is meant to protect the freedom of the software so that users can remove spyware, boobytrap viruses, and patent infringement bait and switches and other malicious things that can sometimes end up in them when companies decide they 'need' these things to protect their interests in the market place.

In GPL code, you -- as the user -- ought to be able to see the source code that was actually compiled, and look for modifications to the binary which violate the GPL and try to take advantage of you as a naive consumer.

It's a real question mark, that I can't determine why the code actually running on the kobo -- doesn't appear to behave the same as the source code release would suggest it ought to. I don't want to jump prematurely to conclusions, but I do want to actually verify why the code behaves strangely.

This isn't a huge time sensitive problem.

But as a security issue, I would like to know for sure that the code Talusan 'thinks' is getting loaded onto his Kobo's is in fact what is there; and that there hasn't been tampering with the binaries by greedy subcontractors, ISP's or governments who are injecting spyware or other malware into the stream illegally / in violation of the GPL.

I've seen too much industrial espionage, up close, in my line of work to take for granted that everything people 'think' is going on, is what is really happening.

[fastrobot]

Originally Posted by Lucas Malor

From man env:

PHP Code:

       -i, --ignore-environment
              start with an empty environment 


Maybe busybox on Kobo starts env with -i implicitly?

Hi Lucas,
That's a good guess, but doesn't make sense ...

The KOBO is only erasing select variables, not all environment variables, so that shouldn't be the problem.
Although, I just tested your idea by doing "busybox sh -i" and "busybox -i sh", and weirdly enough -- NEITHER of them erased all environment variables. The second one is rejected, as it thinks the applet is '-i', and the first one would traditionally cause the shell to be interactive. So -- I don't even know how to pass a '-i' flag to busybox and test your idea... I'll have to read the manual on busybox carefully in a few days.

But-- the problem I've been experiencing is that busybox apps were only erasing variables found in the sanitize list in the source code, the last time I checked.
So, (as an example) if I define a variable called "TEST", that one will not be erased-- but LD_LIBRARY_PATH would be erased.

I also have my doubts that it's busybox itself which is the problem. Because, I don't see how after changing the binary -- that it could still possibly be erasing LD_LIBRARY_PATH. But it does.

It acts a bit like I expect a virus would, eg: the program itself does not have the code, but operates a certain way after being loaded. So -- perhaps busybox is being modified by another program, a kernel driver, or a dynamic library. (?) Makes me suspicious my Kobo has been infected by spyware...

I'll know for sure if the behavior changes in the future, because generally posting that you have found spyware, make the creators of that spyware change the behavior to avoid further detection when other people start discovering it; and then all I need to do is compare the md5 sums to see which binaries were altered.

Anyway, you can install Python on Kobo:

Python 3: https://www.mobileread.com/forums/sho...20#post2885820
Python 2: https://www.mobileread.com/forums/sho...03#post2583203

I cross compiled Python and installed it to do the test with, but it's not python that is causing the issue.
I can run bash shell, or python on the system -- and both of them allow me to inspect system variables.
No variables are ever erased when I run python manually, or bash shell. They were only erased when I run busybox's 'env' program, or sh.

But Note: the cross compilation of Python 2.7.10 (ironically, a bugfix release) is broken on an x86_64 machine and will produce a binary executable that either segfaults, or else is missing a symbol in all the import libraries on the Kobo. SO if you have a 32/64 bit multilibrary PC, you will likely have lots of problems trying to cross compile python 2.7.10 even using Kobo's tools.

Right now I have simply installed a pre-compiled python binary from the Rasperry-PI version 1, Debian distribution. Rasberry Pi Generation 1, uses an older (v6) Arm processor, but old code runs just fine on the Kobo which has a more advanced processor.

I also just bought a second generation Rasberry PI, to compile stuff on for my Kobo since it comes with GCC and does not cross compile but does a true native compile; so the cross compiler bugs in Python shouldn't affect it.

I wrote to the python users group about the issue, but no one there appears to know how to cross compile it either; and so, the only thing left is to contact the maintainers of the C-Python Source code, and ask if they have a way to fix the issue. ( I'll be doing that this week. )

[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).

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).

[fastrobot]

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.

#!/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.

#!/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

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.

[NiLuJe]

No issues on my end, although that's with a custom, self-built TC (from an x86 or x86_64 host). I don't remember having to jump through extra hoops when moving to a x86_64 host (at least for the core Python distribution itself, third-party modules were another kettle of fish), the only thing that needed hand-holding on that front was strace, IIRC.

I'm also using the exact same version of Python I'm building as the host's default Python interpreter, which possibly helps .

┌─(ROOT@(none):pts/0)────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────(/)─┐
└─(1.12:42%:05:11:48%:#)── python                                                                                                                                                                                                                            ──(Wed, Jul 15)─┘
Python 2.7.10 (default, May 31 2015, 03:02:25) 
[GCC 4.9.3 20150413 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import math
>>> import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
>>>

See the rest of the script I linked for the gory details, and this thread for the binaries.

EDIT: And, FWIW:

┌─(ROOT@(none):pts/0)────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────(/)─┐
└─(0.63:42%:05:21:47%:#)── eu-readelf -s /mnt/onboard/.niluje/python/lib/libpython2.7.so.1.0 | grep Py_InitModule                                                                                                                                            ──(Wed, Jul 15)─┘
  898: 000c49e9    460 FUNC    GLOBAL DEFAULT       12 Py_InitModule4

[fastrobot]

Thanks!, NiJuLe,

I am compiling with Ncurses6.0 pre-release, because I need the SGR mouse interface (Xterm 1006 mode) that was just added -- so the binaries may not be the best option for me as I need it to link against a new version of NCurses.... and I'm not sure I can just replace Ncurses 5.9 without recompile.

But looking at the gory details in your link, there were essentially six switches and three environment variables different in how you compiled python as compared to how I did it; namely -fwrapv, --enable-unicode=ucs4, --with-libc="", --with-system-ffi, --with-system-expat, and --with-fpectl

and for system variables, you defined these extras.

export _PYTHON_HOST_PLATFORM="linux-arm"
export ac_cv_path_PKG_CONFIG="pkg-config"
export ac_cv_buggy_getaddrinfo=no

I don't have a system expat in the Kobo, so I left that switch off -- but changed all the others and removed the debugging switches I had put in (as those cause the init symbol to disappear -- and why, I have no clue... )

I'm not sure which one was the root of all evil in my earlier problems, but when I made those changes and exported environment variables for all the ac_cv variables instead of passing them to .config directly, the segfaulting problem went away even without applying any of the patches you had in your file.

I now have a plain vanilla unpatched python 2.7.10 that doesn't segfault, and the Init symbol is correctly defined. So I'm pretty darn happy. Thanks. You probably saved me a week of messing around... I was going to upgrade my system python from 2.7.5 to 2.7.10... but I doubt I need to.

[NiLuJe]

@fastrobot: Happy to help, and to save one more soul from the headache of x-compiling Python .

That said, I have to admit I'm not quite sure which part of those changes might have jogged things up either... .