Skip to main content

Scratchbox Cross-compiling Made Easy

By
Often Getting problems with corss compiling here is the perfect solution, read on.
Scratchbox is a configuration and compilation environment for building Linux software and entire Linux distributions.
The basic idea of Scratchbox is to offer developers an environment that works and looks like the target environment before the target environment is available.
The Scratchbox is an environment that you log into like you would log into some machine. However, the Scratchbox tools can be used either inside or outside of Scratchbox download
scratchbox-core
http://www.scratchbox.org/download/files/sbox-releases/1.0/tarball/scratchbox-core-1.0.1-i386.tar.gz
scratchbox-libs
http://www.scratchbox.org/download/files/sbox-releases/1.0/tarball/scratchbox-libs-1.0.1-i386.tar.gz
scratchbox-toolchain-arm-glibc
http://www.scratchbox.org/download/files/sbox-releases/1.0/tarball/scratchbox-toolchain-arm-gcc3.3-glibc2.3-1.0.1-i386.tar.gz
untar all tar ball using tar -xzf command
then run
$/scratchbox/run_me_first.sh

’run_me_first.sh’ asks you some questions, just use defaults. After this we need to add user for
Scratchbox. User must be some user that you have in your system.

Cross-compiling outside Scratchbox
$/scratchbox/compilers/arm-gcc-3.3.4-glibc-2.3.2/bin/arm-linux-gcc -Wall -o arm-hello hello.c

Cross-compiling in Scratchbox
Scratchbox is a chrooted cross-compilation environment. This means one has to log into the Scratchbox like one would log into a some real machine
You can log into the Scratchbox system with a command: ’/scratchbox/login’. You should get some welcome messages and your prompt should change to something like
’[sbox-HOST: ~] > ’..

The Scratchbox prompt ’[sbox-HOST: ~] > ’ tells you that you are in Scratchbox environment and that you are using target called HOST. In Scratchbox you can have multiple targets which means that you can compile programs for many different architectures and settings.
then create a target for our cross-compilation needs.

[sbox-HOST: ~] > sb-conf setup MYTARGET -c arm-gcc-3.3.4-glibc-2.3.2
-t qemu-arm
[sbox-HOST: ~] > sb-conf select MYTARGET
[sbox-MYTARGET: ~] >

Scratchbox comes with ARM emulator QEMU.

[sbox-MYTARGET: ~] > gcc -Wall -o sb-arm-hello hello.c
as we are inside the Scratchbox environment we can also run the program although it is an ARM
binary and we are on X86 machine. This was because we have the emulator:
[sbox-MYTARGET: ~] > ./sb-arm-hello
Hello World!


Scratchbox website (http://scratchbox.org/).
Installing Scratchbox (http://www.scratchbox.org/documentation/docbook/installdoc.html).
QEMU (http://fabrice.bellard.free.fr/qemu/).
Labels:

Comments

Post a Comment

Popular posts from this blog

Dotnet, .Net 3.5, 2.0, C# Interview Questions

By
Few questions on dotnet, C# 2.0, 3.5 On Object oriented concepts 1)What is inheritance with e.g 2)What is polymorphism -function overloading -Function overriding -virtual keyword use -Static keyword and use -Abstract classes -Interface -Object 3)What is threading and how do we use in realtime application(cognizant) 4)What is threadpooling, lock, monitor(write code sample) 5)Architecture of current project 6)Session state, diffrent types of state management. 7)What is Application_Start, how it works. 8)Type of authentication in asp.net 9)How to configure ASP.NET application. 10) What is Impersonation. 11) What is WebService, WSDL, UDDI, Discovery, asmx files. 12) How to implement WebService and use it. 13) When to use WebServices. 14) WPF, how to implement(BOA) 15) Testing concvepts. 16) Test attributes 17) Flow of Automation Test Method execution 18) Features of dotnet 3.5 19) CLR, garbage collection 20) Finally block 21) Manifest, Metadata, MSIL 22) Assemblies, Type of assemblies, str...
2 comments
Read more

Remote debugging for ARM target board

By
Remote debugging for ARM target board With GDB one can both trace and modify code and data flow, and otherwise analyze the behavior of code, without explicitly changing any of it. Rather than run a full-blown instance of GDB on the target platform, you can use GDBserver , a program that lets you run GDB on a different machine than the one on which your program is running. The advantage of using GDBserver is that it needs just a fraction of the target resources that GDB consumes, because it implements only the low-level functionality of the debugger -- namely setting breakpoints and accessing the target processor registers and read/write application memory. GDBserver takes control of the application being debugged, and then waits for instructions from a remote instance of GDB running on a development workstation. Remote target needs to have debugging stub (gdbserver), The gdbserver is also referred to as the 'stub' and must be cross-compiled for that targ...
3 comments
Read more