This entry was originally posted on the ARM and Keil Tools Blog
As new ARM platforms such as micro-servers hit the market and hyper-scale computing users queue up to take advantage of the incredible 90% power and space savings that these packages offer, it is surprisingly easy to migrate your applications from x86 to ARM.
A lot of the hard work has been done for you already – most of your tools will already have been ported. To troubleshoot those tricky exceptional cases I am going to show you how to use our software, Breeze, to examine problem applications in more detail, letting you debug configuration issues in minutes. I will also discuss more advanced topics such as cross-compiling and how Breeze was migrated to ARM in the first place.
Getting started with a standard Linux tool kit
Your ARM micro-server will probably come with some flavour of Linux installed. Many of the more popular distributions have released ARM builds with a comprehensive repository of pre-built tools.
Ubuntu and Fedora already have 20,000+ applications and libraries. These can be installed with the apt-get command as soon as you log into your server.
Other distributions are quickly catching up and the list of available pre-built packages is growing by the day.
Compiling from source code
If you have developed your own software you will have to recompile it for the ARMv7 architecture. Many Linux applications are open source so you can easily port software from other developers as well.
For builds that employ commonly used tools such as GCC and GNU Make, you may not need to make a lot of changes to the build process, but even simple changes, like updating library paths can be tricky if you don’t know where to look.
If it won’t compile or there’s an error
When setting up a new system there is always room for tiny differences that can cause a problem. Breeze can show you what those differences are and solve your problem quickly. Breeze can trace your installation or build process on your old system and on your new ARM server and show you what is happening inside the build.
Breeze visualises your program hierarchy and captures details such as program arguments and dependencies.
You can download a trial from www.ellexus.com. In order to trace and compare the two programs you’ll need to download it for your old x86 machine as well as your new ARM server.
Trace your program or installation process on both machines using the trace-program.sh script that comes with Breeze. You need to specify a log file followed by the command and arguments for your program.breeze_unzipped> ./trace-program.sh -f trace.logfile.arm make all-install
Start the full Breeze application and import both traces using File Menu > Import Trace. You can then compare the traces using the Trace menu > Comparison Dialog.
The Comparison Dialog lets you compare program arguments and environment as well as libraries, network locations and files read and written to.
Step 4: Examine your programs in detail
If you don’t have a `good’ trace to compare your problem to, you can examine each trace in detail by itself. For example, if you have an error message complaining that a file is missing, you can see where your application is looking.
In the figure above, Breeze is telling me that a load of my Xulrunner libraries are missing so I’ll need to install those in order to run Firefox properly.
Can I cross compile my applications on my old servers?
You may want to start to prepare your applications before your new server arrives. For this case you’ll need to install a cross compiler on your old server. There are many free ones available as well as others with commercial support. I use the CodeSourcery cross compiler from Mentor Graphics.
For simple C and C++ applications you can just download their tool chain and swap gcc for the alternative cross compiler. Just make sure the installation directory is in your PATH.
For most applications this will be sufficient and you’ll be able to copy the binaries across to your ARM server without a hitch.
Cross-compiling libraries and complex applications
Breeze is a complex application with custom libraries, so when we set up our cross compiler we had to do a little bit more work. We had already compiled the Breeze libraries on an ARM platform so we were able to trace and compare the default cross-compiler job with the compilation job on the native ARM platform.
The two traces looked almost identical, which was a good start. Only the name of the compiler was different, until we started to compare program arguments. Although the arguments for gcc were the same, we noticed that the native ARM compiler passed some extra arguments to the linker.
It seemed that the default setting for our cross compiler was to compile for ARMv5 and soft float, but the native compiler has been built for ARMv7 and hard float. We chose a CodeSourcery cross-compiler that supported ARMv7 with hard float and added those options into our linker options. This time the cross-compiled version of Breeze worked just fine.
In general, migration problems are easy to fix once you can look inside your applications and scripts. Often the issue is as simple as a miss-typed environment variable or a forgotten local user setting. Breeze won’t tell you what the problem is, but it will give you enough information to work it out or ask more specific questions. Most of the time your programs will work first time, but when they don’t Breeze is there to help.
Ellexus are the developers of Breeze, a Linux dependency tracing tool that shows you what your programs are doing as they run. You can quickly search trace data to trouble shoot a problem build or installation.