This environment can only build STATIC linked programs to run on the Kindles!
But since building STATIC linked programs seems to be a common speed-bump ...
It will build dynamically linked programs, but for uClibc, which is not what the Kindles are using.
* * * *
Presumes a QEMU that provides: qemu-system-arm is already installed.
Confer with your Linux package manager about that subject.
Give my hand-built one a try, attached to post:
and provide feedback on your results.
Make a work place and grab the tar-ball:
core2quad ~ $ mkdir BLDS
core2quad ~ $ cd BLDS
core2quad BLDS $ wget http://drpbox.knetconnect.com/KeK/system-image-armv6l.tar.bz2
Extract the contents onto the current working directory and then make that directory current:
core2quad BLDS $ tar --extract --file=system-image-armv6l.tar.bz2
core2quad BLDS $ cd system-image-armv6l
Make a quick check that the install is working on your host machine:
core2quad system-image-armv6l $ ./run-emulator.sh
qemu-system-arm: pci_add_option_rom: failed to find romfile "pxe-rtl8139.rom"
Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0
* * * *
VFS: Mounted root (squashfs filesystem) readonly on device 8:0.
Freeing init memory: 100K
8139cp 0000:00:0c.0: eth0: link up, 100Mbps, full-duplex, lpa 0x05E1
Not using distcc.
Type exit when done.
(armv6l:1) /home # gcc -dumpmachine
(armv6l:1) /home # uname -a
Linux (none) 3.4.0 #1 Sat Jul 14 08:57:51 CDT 2012 armv6l GNU/Linux
(armv6l:1) /home # exit
core2quad system-image-armv6l $
Now display the deb-environment.sh script, read the comments at the top.
The above, default, system image only has a 32Mbyte /home directory.
For development, you want a larger /home directory.
If you execute ./dev-environment.sh without setting any environment varables it will create a 2Gbyte /home directory file for you.
You can always use the ./dev-environment.sh script for entry, it will not over-write any existing hdb.img.
How do you get your files in and out of the emulated arm system?
Read and follow the comments in ./native-build.sh;
Just mount the hdb.img (the /home when inside the emulated system) and copy to and fro as required.
core2quad system-image-armv6l $ sudo mkdir /mnt/hdb
core2quad system-image-armv6l $ sudo mount -o loop hdb.img /mnt/hdb
- - - copy, copy, modify, copy - - -
core2quad system-image-armv6l $ sudo umount /mnt/hdb
Just 'wget' your sources while inside the environment, for an example tinycc (which defaults to building as dynamicly linked - at least this one does):
core2quad system-image-armv6l $ ./dev-environment.sh
* * * *
Type exit when done.
(armv6l:1) /home # wget http://drpbox.knetconnect.com/KeK/tinycc-patched.tgz
(armv6l:1) /home # tar -xf tinycc-patched.tgz
(armv6l:1) /home # cd tinycc
(armv6l:1) /home/tinycc # (edit configure cpu list to include armv6l)
(armv6l:1) /home/tinycc # ./configure
(armv6l:1) /home/tinycc # make
(which will fail when it tries to build documentation, so what?)
(armv6l:1) /home/tinycc # ./tcc -v
tcc version 0.9.25
(which by the way, is a lie -- this is the not yet released 0.9.26)
We know that it does not use any of the whizz-bang new syscalls in Linux-3.4, so it does not matter that it was built against version 3.4 header files.
This copy of tinycc will also "build static" executables.
It will build "shared library" executables for uClibc (its own environment)
It might be possible to build "shared library" executables with it for a glibc environment also - provided you get all the system library over-ride commands required correct on your tcc command line.
Something always needs to be left as a: "student exercise"
As in: what became of /usr/include/stddef.h ?
Continued at post: http://www.mobileread.com/forums/sho...7&postcount=76
Where the final tcc-static is built.