FAQ List

1. Why to cross-compile everything from scratch instead of using natively compiled binaries like everybody else does?

Speed, control and quality. You get much faster turnaround and better integration with continuous building / regression testing. This enables much more distributed development.

Note that commercial embedded distributions allow you to cross-compile only software they are providing, with their systems you can't just get some Open Source software from the internet and expect to be able to cross-compile it.

2. How can I use the same CPU transparency device for different users using different versions of the Scratchbox?

You can specify in which port the Sbrshd daemon listens to connections. When you upgrade to newer Scratchbox with newer Sbrshd daemon, just run the daemon at different port on the CPU transparency device. When users upgrade to that Scratchbox version, they just need to change the .sbrsh files in their Sbox home directory to contain the correct target port number (add ':' after the target IP address, example <ip>:<port>, 192.168.0.100:1202).

3. What environment variables are used to control scratchbox

If you have installed scratchbox from tar.gz files a list of all environment variables used by scratchbox are described in /scratchbox/doc/variables.txt. Debian packages install the documentation to /usr/share/doc/scratchbox-core

4. How do I test in my [script|Makefile] whether I'm running inside Scratchbox?

• In shell scripts:

  if [ -f /targets/links/scratchbox.config ]; then echo yes; fi

• In Makefiles:

  SBOX = $(shell if [ -f /targets/links/scratchbox.config ]; then echo yes; fi) ifeq ($(SBOX),yes) # do sbox specific stuff endif

5. How my [script|Makefile] can know which target [target|CPU|C-library] is currently effective inside Scratchbox?

This information is in 'scratchbox.config' file in a format which can be used both:

• In shell scripts:

  source /targets/links/scratchbox.config echo $SBOX_CPU

• In Makefiles:

  include /targets/links/scratchbox.config all: $(SBOX_CPU)-program

Note that 'configure' scripts have a generic way of handling this, above is intended for things that are Scratchbox specific.

6. How I can see the size of (cross-)compilation object cache, number of cache hits/misses and how I empty the cache?

[sbox-HOST: ~] > ccache -h

7. How I can see what commands are executed (over the network) on the CPU transparency device?

For older (before 0.9.8pre4) scratchbox versions all commands executed with CPU transparency feature are logged to '/tmp/coutransp_$USER.log'. If environment variable SBOX_CPUTRANSPARENCY_VERBOSE has a value (other than '0' or 'no'), a message is outputted to STDERR everytime CPU transparency is used. SBOX_CPUTRANSPARENCY_VERBOSE may cause problems with some configuration scripts

In newer (after 0.9.8-pre4) versions logging of commands executed with CPU transparency is controlled with SBOX_CPUTRANSPARENCY_LOG which is used to provide name of the CPU transparency logfile. If the environment variable is empty logging is disabled.

8. How I can see what environment variables the programs run on the CPU transparency device will get/see?

Run the following command (if you have a shell compiled for your target):

[sbox-ARM: ~] > /scratchbox/tools/bin/misc_runner \ /bin/sh -c "set"

9. CPU transparency doesn't work for program X, what can I do? How do I disable CPU transparency?

99% of the programs do not need any changes for cross-compilation as nowadays Scratchbox should handle also CPU type configure checks automatically. In case you come across software that queries CPU type in a way Scratchbox can't fake, you can always disable CPU transparency and configure that software manually (assuming it can be cross-compiled normally). For ARM you could do it like this:

export SBOX_DEFAULT_GCC_PREFIX="host-" export SBOX_DISABLE_CPUTRANSPARENCY=1 CC=arm-linux-gcc ./configure --host=arm-linux

This way you still profit from the Scratchbox sandboxing feature.

10. Can I use [some] service that's not in Scratchbox (e.g. X) from inside it?

Because Scratchbox uses chroot for sandboxing the compilation and its configuration, only file based communication methods (unix sockets, pipes etc) are limited. This can be handled through '/tmp'-directory as Scratchbox shares it with the rest of the system. Usually servers place their sockets into '/tmp' by default and most of others (and their clients) can be told to do that, so there should be no problems.

11. How do I run gdbserver on target, control that with GDB running inside Scratchbox (so that it loads correct libraries and source code files) and see the GDB output in DDD running outside Scratchbox?

See Integration with IDE tools.

12. Can I connect my Scratchbox machine to Internet?

This is not recommended because Scratchbox CPU transparency requires your machine to do NFS exports and it installs a couple of suid-root / sudo binaries to your system (so that normal users can use Scratchbox).

13. Where can I get more help?

Try asking your question on IRC channel #scratchbox on Freenode or in one of our mailinglists.

14. Why I cannot use Scratchbox as root?

Scratchbox is intended to be used and be usable on developer desktops which are administrated by other people. For compilation root privileges shouldn't be needed. It shouldn't be needed for building packages either, for that fakeroot(-net) should be enough. Root is needed only when you install packages or run the installed software and even this only for very few system software packages. The main purpose of Scratchbox is building software.

Additionally, running Scratchbox as root is an easy way to shoot yourself into foot, and as you're compiling whole distributions in Scratchbox there's a lot of software that might contain e.g. trojans. Sandboxing and faked root privileges make things a bit more secure.

15. How do I run in Scratchbox binaries that need real root privileges (not just "fakeroot")?

If you've e.g. compiled X server for ARM, and would like to run it as root on the target (because it doesn't run/work correctly without root privileges), you can:

• login to the ARM sbrsh device as root:
  $ ssh root@arm.device
• chroot to the Scratchbox NFS mount in your ARM device home directory:
  # chroot /home/username/[IP-number]-[target name] /bin/sh
  (note that this requires that you've compiled shell for the target in Scratchbox)

Now that you've been chrooted to Scratchbox directory, you can run as root any software you've cross-compiled in Scratchbox:

# Xfbdev -screen 320x240x16@90 -ac :1 &

Note that not all of the Scratchbox contents are NFS mounted onto target device, only the relevant directories (see your ~/.sbrsh file for the details). Also, you should keep an sbrsh session open inside Scratchbox so that the NFS mounts won't expire while you're working in the other session. Alternatively, you can start the sbrsh daemon with the --mount-expiration none option so that it never expires the NFS mounts.