Previously in this blog series, I discussed a few options for cross-compilers and IDEs compatible with Windows (and in fact Linux and Mac as well). I demonstrated how to build the Boost library and how to generate a cross-compile Code::Blocks project for Wt using CMake.

I’m now going to cover compiling of the hello.wt build target that is included as one of many in the generated WT Code::Blocks project. A build target is typically a variant of the same program i.e. targeted for a different platform, targeted for debug etc. but generally the program itself is functionally similar. In this instance, CMake has provided us with various different sample programs that are not functionally similar, each configured as their own build target. This is fine for our purposes but if you wished you can create a separate, stand-alone project from these build targets; instructions for this can be found in Code::Block’s Help menu.

I have chosen to focus on hello.wt as it’s the perfect template for creating my own program. I can either simply modify hello.C or I could create a new project with the Hello.wt settings as a guideline. Hello.wt is programmed to demonstrate how to:

• Start a web-server.
• Create a new session when a user connects.
• Create widgets and add them to the widget tree (a hierarchy representing a webpage).
• React to events using the signal/slot mechanism.
• Read user input and update widgets accordingly.

Simply put, it sets up a web address a user can connect to, displays a message asking for the user’s name and updates the widgets to display that name back to the user, all without refreshing the page, which is where the signal/slot mechanism comes in handy! Essentially all the basic building blocks needed to expand from for my own program. For more information on actually building an application, you can look to the Wt website where there are examples, guides, a wiki, full documentation and an active user forum.

Building hello.wt isn’t all that difficult, but first I must add the Code Sourcery cross-compiler details to Code::Blocks. This is a one time occurrence and I can reuse these settings in future projects. To add a new compiler option within Code::Blocks I must navigate to Settings > Compiler and debugger settings. By default I’m taken to the Global compiler settings page. Oddly I can only create a new compiler entry by copying an existing entry; thankfully though, there’s already an option GNU ARM GCC Compiler that’s the perfect template. I will simply add my details to this compiler option but alternatively if I had several ARM compilers, I could create a copy of this for each one.

Under Toolchain executables I need to inform Code::Blocks of the names and locations of the various programs used to build a project, here’s the list of the settings I used:

Under Search directories > Linker I added the location C:Sourcery_G++_Litearm-none-linux-gnueabilibc to point to the libraries of the tool-chain.

Depending on the architecture and the optimisation you’re looking for you may also need/wish to configure settings on the Compiler Flags tab. You can find out what settings you should be using by reading both the Code Sourcery manuals and reading your embedded device’s documentation.

Now that all that’s done, I have to set hello.wt as my active build target. This can be done from one of the tool-bars or from the menu it’s Build > Select target. Finally, I must inform hello.wt that I wish it to use my ARM compiler that I configured previously. I can either do this by right-clicking on the WT project and selecting Build options… or from the menu it’s Project > Build options… . From here I can select my compiler from the drop-down list and that’s a wrap! I can now build my project, though the first time as large sections of Wt are also being compiled this can take around 8-12 minutes. The executable file hello.wt will be generated, it’s worth noting that executables on Linux do not all have a single extension like exe in Windows.

There are three approaches to running a compiled program on the target device. The first requires that I include the Code Sourcery tool-chain when building my root file-system. This is a step usually partaken when creating your own distribution/flavour of Linux, as such I will not be discussing the approach in this blog series. If you find yourself lucky enough that Code Sourcery is part of your distribution’s root file-system, then you can run your program as if it had been compiled natively right on the target device and you would have no need to read any further.

The remaining two approaches require that I copy the Code Sourcery tool-chain onto my target device which, alas is not quite as easy as copy and paste. The approach I take assumes the target device has a network connection. I can either download the following archive directly from the internet or first to my PC and host a local web-server, which I highly recommend as it’s a simple approach to transferring files that avoids the spotty and varied results of configuring a shared network drive and saves the tedious to and fro action of transferring by USB stick. Almost all GNU Linux distributions come with the software/command wget pre-installed that can be used to fetch files over HTTP, HTTPS or FTP.

Using this command I download the file IA32 GNU/Linux TAR from the Code Sourcery website (or my local web-server). The file is found on the same page I downloaded my Windows installer from. This file contains the standard x86 Linux copy of the Code Sourcery cross-compiler and is not meat for use on the ARM target device, however inside this file is the folder arm-none-linux-gnueabi/libc which contains the ARM edition of the compiler and tool-chain. This folder is also supplied with the Windows edition of the tool-chain but due to the differences in file-systems, important symbolic links (short-cuts) and file permissions are lost in translation.

I proceed by extracting the TAR file and copying libc to the root of my file system, though in practise the location or name isn’t important. It’s now safe to delete the TAR and the remaining extracted files, in fact, if I do not intend to perform any compiling with Code Sourcery directly on the device, it’s safe to also delete the libc/usr/include sub-directory and any .so or .a files. Here’s a quick example of my command line operations:

• wget https://sourcery.mentor.com/sgpp/lite/arm/portal/package8739/public/arm-none-linux-gnueabi/arm-2011.03-41-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2
• Fetches the IA32 GNU/Linux TAR file from the internet.
• tar -xvf arm* arm-none-linux-gnueabi/libc
• Extracts the correct ‘libc’ folder to the current directory. Option ‘x’ is to extract, ‘v’ to ask for feedback of the extraction process, ‘f’ to allow us to specify the file-name. ‘arm*’ says to extract all files beginning with the text ‘arm’, this saves me typing out the really long file-name, just make sure you have no other files beginning with ‘arm’ in the same directory!
• rm -vr ./libc/usr/include
• Remove unwanted files and folders. Option ‘v’ is the same as with tar and will provide feedback of the process, ‘r’ is recursive, meaning to repeat the removal process in all subdirectories. Be VERY careful with this command, worst case scenario you delete everything!
• find ./libc/ -iname “*.so” -exec rm ‘{}’ ‘;’
• find ./libc/ -iname “*.a” -exec rm ‘{}’ ‘;’
• Remove all .so and .a files. As we do not know their names and due to limitations of the rm command, we use the find command instead.
• rm -vr ./libc/armv4t
• rm -vr ./libc/thumb2
• Remove more unwanted folders, these are in fact alternate tool-chains for different versions of ARM processors. Check the documentation to know if you should be using one of these instead of libc.
• sudo mv ./libc /
• Move libc to the the root directory, ‘sudo’ is used to grant admin access to the root directory and will prompt you for your admin password.

This may seem a little complicated but it’s essentially 8 brief command-line commands to download, extract, prepare and place the tool-chain onto the target device ready for use (3 if you don’t mind a little bloat from the un-deleted files and folders). I’m now ready to continue exploring the remaining two approaches to running my program on the target system.

The second approach is to dynamically link a compiled program to the tool-chain at runtime. This is the simplest and quickest approach for me to test out my hello.wt program. However I should avoid this option unless I have no way of knowing the location of the tool-chain on the target device prior to building my program. I can not debug with this method and I must always type the following to run my programs, which is cumbersome in the long run, here’s an example command to run hello.wt:

• /libc/lib/ld-linux.so.3 –library-path /libc/lib:/libc/usr/lib /path/to/hellowt/hello.wt –http-port 10000 –http-addr 0.0.0.0 –docroot .
• This command uses ld-linux.so.3 to link hello.wt to the Code Sourcery libraries. The commands after hello.wt will cause the program to load a web-server on the default interface on port 10,000. To test if this has worked, from a web-browser on the device’s network, type http://my.device.ip:10000/

I took this opportunity to test my program and it worked just as expected, which is brilliant as it has been a rather long road! I performed the above steps by downloading hello.wt with wget and running the following command, used to set file permissions, to make the program executable: chmod 100 hello.wt. For security reasons, if you haven’t read up on chmod, I strongly recommend doing so. If you have decided to follow my footsteps and receive an error at this stage, I recommend back-tracing your own footsteps before proceeding, feel free to ask for advise in the comments section of this post.

The third approach is the method I will be looking to use long-term for this project. It enables me to specify the locations of the Code Sourcery libraries at compile-time so that I can avoid the long command of approach two and the difficult set-up of approach one whilst still being able to debug my program. To set this up I would typically jump back into Code::Blocks and navigate back to my Compiler and debug settings > Linker settings. However, as Wt was built with CMake, the CMake project files handle the entire build process and bypass Code::Blocks settings. In a rather quick and rough manner I navigate to MyWtBuildDirectoryexampleshelloCMakeFileshello.wt.dir and open in WordPad the file flags.make. Here is where I can specify my custom compiler and linker flags. I add the following to the end of the CXX_FLAGS line:

-Wl,-rpath=/libc/lib:/libc/usr/lib -Wl,–dynamic-linker=/libc/lib/ld-linux.so.3

Essentially I’ve added the same command from approach two, only it’s now hard-wired into the program. I can now re-build my program from Code::Blocks, copy over the new hello.wt, set the chmod permissions and run it with a simple:

./hello.wt

I think I’ll take a little break here! Look forward to a post on remote debugging next time.

Alistair
QuickForge – Rapid 3D Printing