It would be really nice if people could just install Scratchbox package to their machines, install required target
device(s), check "Scratchbox cross-compilation and Xnest testing support" checkbox in their Eclipse, KDevelop or Anjuta
Integrated Development Environments and then re-compile and test their software as usual, but for different CPU
architecture than the one in their own workstation. This would require the IDEs to do the following things.
1. Sources
Keep/put the sources inside Scratchbox into user's home directory there and edit the sources from there.
2. Building
Build the sources sandboxed to Scratchbox. Currently this can be done like this:
sbox-command $HOME/source-dir/ ./configure
sbox-command $HOME/source-dir/ make
Where given path is relative to Scratchbox root directory.
'sbox-command' is a script like this:
#!/bin/sh
# run the given command sandboxed to the user's Scratchbox
/scratchbox/sbin/chroot-uid /scratchbox/users/$USER $HOME/sbox-run $*
and 'sbox-run' is a script in '/scratchbox/users/$USER$HOME/' (user's home directory inside Scratchbox) similar to
this:
#!/bin/sh -l
# go to directory given as first arg and execute rest of the args there
cd $1 shift
# export here environment variables required by the command to execute
export DISPLAY=localhost:1 $*
It's user specific so that users can (through the IDE or manually) set their own environment variables etc. If you
want to run shell scripts that reside outside Scratchbox as sandboxed, do it like this:
Given script will then be run in the given path inside Scratchbox.
3. Run the cross-compiled programs in a debugger
If you want to debug a program you're running on a target device, you need to use either a gdb or gdbserver compiled
for that target. Gdbserver doesn't need any significant amount of memory (unlike gdb) so it's use is desirable. If
there's a gdbserver compiled for the target device, you can use 'sbox-command' also with it (inside Scratchbox target
binaries are run automatically on the target when invoked):
And in DDD prompt tell GDB to contact and control the arm-gdbserver running on the target:
(gdb) target remote HOST-IP:PORT (gdb) break main (gdb) cont
(After gdbserver has stopped the arm binary at the 'main' breakpoint, gdb should have loaded the symbols for the arm
binary so that you see them in DDD.)
The reason why GDB has to be compiled and run inside the Scratchbox is that otherwise it wouldn't load the correct
libraries etc. for the program you're debugging. Paths to them are different outside the Scratchbox.
4. Run/test the cross-compiled programs
Command line programs can be run just by using 'sbox-command'. X programs need an X server. For this the IDE could
just run Xnest outside the Scratchbox:
Xnest :1 -ac -geometry WIDTHxHEIGHT &
And then export a suitable DISPLAY variable for the target binaries:
