Chumby One + cross compiler + Qt

I recently bought a chumby one from Woot. It’s an extremely hacker-friendly device with a 454 MHz Freescale i.MX233 ARM processor, 3.5 inch touchscreen, USB port, accelerometer, speaker, internal USB wi-fi module, and an internal microSD card. It boots from the microSD card, so it’s pretty much un-brickable as long as you keep a backup of the original SD card contents.

It’s an awesomely cool device out of the box, but all of the GUI stuff is based on Flash. Now that’s wonderful and all, but I’m just not much of a Flash guy. I really like working with Qt on embedded devices, so I got a cross compiler up and running, allowing me to design stuff on my desktop computer (running Ubuntu 10.04) and deploy it onto the chumby. I have learned during my time as a developer to document what I did when I do things like this! Two years later it’s hard to remember exactly what I did. I learned this the hard way and now I always document a procedure like this as I’m going through it. I figured while I’m documenting it, I might as well share it with the world. These instructions will walk you through creating a modern cross compiler toolchain for the i.MX233 (compatible with the chumby’s libc), using that toolchain to compile Qt/Embedded 4.7.2, and finally, creating apps on your build machine and running them on the chumby.

The basics

Start out with an Ubuntu 10.04 (“Lucid Lynx”) installation. This procedure will probably work in newer and older versions, but I’m assuming you’re using 10.04. I’m going ahead and using an amd64 install of Ubuntu, but it should work fine in an i386 install as well. Once you have that installed (however you want to do it — directly on the computer, Wubi, in a virtual machine, or whatever other crazy install method you can conjure up), we’re ready to begin.

First of all, we need to install some prerequisite packages for various purposes. In a terminal window, type:

sudo apt-get install build-essential bison flex texinfo automake libtool cvs libncurses5-dev subversion

crosstool-NG

After getting all this stuff downloaded and installed, we’re ready to start creating the cross compiler. Download crosstool-NG (I used version 1.10.0) and unpack it somewhere. crosstool-NG is absolutely amazing. It saves so much trouble while creating cross compilers. You just go through a menuconfig interface similar to the Linux kernel’s menuconfig interface, telling it exactly what you want. If you’re lucky, you just tell it to work and it grabs all the source code, patches it, and compiles it automatically, leaving you with a fully-functional cross compiler after a half-hour or so. In this case, I have verified that the configuration I’m going to give you will work. In other cases, you may have to do some trial and error because some versions of C libraries and binutils don’t work with some versions of gcc. Generally you want to use tools that came from the same time period, as this will give you a better chance of everything working together. Anyway, go into the crosstool-ng directory in a terminal, and type:

./configure --local
make

The –local option tells crosstool that we will be running it directly out of the directory we unpacked it to. Otherwise it would install itself into /usr/local or somewhere like that. I prefer it this way rather than putting it into /usr/local. This should create a script called ct-ng. We will be using this script to configure and create the toolchain.

So let’s start setting up the toolchain! I’d just give you the config file, but I’d rather walk you through setting up crosstool so you better understand how it works. Type:

./ct-ng menuconfig

After a few things finish setting up, you’ll be greeted with graphical interface in the terminal. You can move up and down with the arrow keys. The enter key will go to the selected item. Hit the Esc key twice to go back. Let’s go through the sections:

Paths and misc options

It turns out I’m going to break my own rules here. I’m going to choose newer compilers and binutils with an older glibc. It happens to work in this case, so no harm done. I’m using an older glibc because the glibc on the chumby’s root file system is version 2.8, so I’d like our version to match. If we use a newer version, some binaries will not be compatible with the older glibc, so we’d have to replace chumby’s glibc, and I’d rather not.

Highlight Use obsolete features and press the space bar to select it. This will allow us to choose an older glibc that is probably not compatible. (We’re actually going to use eglibc, which plays better with our setup than glibc)

Scroll down and you’ll notice that Prefix directory is set to “${HOME}/x-tools/${CT_TARGET}. This means it’ll create a folder called x-tools in your home directory which will store all cross toolchains you create. I left this alone, but if you’d like it elsewhere, go ahead and change it now.

Keep scrolling down until you find Number of parallel jobs. This one will save you some time if you have a dual- or quad-core processor. While creating the toolchain, this will allow some of the files to be compiled concurrently, making better use of your multiple-core CPU. For you techies out there, it’s letting you specify the -j option passed to the make commands that will run. I generally set this to the number of cores I have available. Since my 4-core Core i7 has hyperthreading, I normally choose 8. In a VMware virtual machine where I have given the VM two cores to work with, I’d choose 2. Different people have different opinions on what’s the best value here, but I’d say stick with the number of cores you have available and you’ll be fine. If you pick too high of a value your entire system will slow to a halt, and if you pick too low of a value, you’ll be under-utilizing your CPU.

Okay, sorry about that long explanation. Now we’re ready to move to the next section. Hit Esc twice to go back to the menu. Move down to Target options and hit enter.

Target options

Highlight Target Architecture (alpha) and hit enter. Scroll down to arm and hit the space bar. We are telling crosstool-NG that we’re building a cross compiler that will target the ARM architecture, which is what the chumby uses.

chumby uses a Freescale i.MX233, which is an ARM926EJ-S. We need to tell crosstool which CPU we’re targeting, so scroll down to Emit assembly for CPU and hit enter. Type “arm926ej-s” (without the quotes) and hit enter.

Scroll down to Floating point and hit enter. Scroll down to software and hit the space bar. The i.MX233 does not have a hardware floating point unit, so we need to choose softfloat here (otherwise, the kernel emulates hardware floating point instructions, and it gets terrible performance).

We’re done here, so hit Esc twice, move down to Toolchain options, and hit enter.

Toolchain options

Our toolchain will be called “arm-chumby-linux-gnueabi”. The “chumby” part of this is called the vendor string, so we need to configure it as such. The vendor string makes no technical difference–it’s purely a cosmetic thing. Scroll down to Tuple’s vendor string, hit enter, backspace until you have erased “unknown”, type “chumby”, and press enter.

Exit this menu and go to the Operating System menu.

Operating System

Change Target OS to linux. You’ll notice that the kernel version is set at 2.6.37. It may not make a huge difference in some cases, but in this case, we need to pick a kernel version closer to the chumby’s kernel (2.6.28-chumby). Otherwise, the touchscreen library won’t work. We could probably get a tarball of the chumby’s kernel and be exact, but rather than bother with that, I set it at 2.6.27.57. Once you’ve made that change, exit this screen and go to Binary utilities.

Binary utilities

We’re not going to change anything here, but this is where you would change the version of binutils. Leave it at version 2.20.1.

Exit again and go to C compiler.

C compiler

Leave gcc at version 4.4.5. You need to scroll down under Additional supported languages to C++ and hit the space bar to make sure the toolchain is enabled for compiling C++. Now move down to C-library.

C-library

The C library is already set as eglibc, which is what we want. Change eglibc version to 2_8 (OBSOLETE). Normally this would be a bad idea to use an old version of eglibc combined with newer binutils and gcc, but we need version 2.8 in order to be compatible with the chumby’s provided glibc, and it works OK with the newer binutils and gcc. This is the sole reason we had to enable Use obsolete features when we were starting out. We also need to add an extra option here to fix a problem I encountered when I first tried to build this toolchain. Go to extra target CFLAGS and set it to “-U_FORTIFY_SOURCE”. Exit this screen and head over to Debug facilities.

Debug facilities

Go ahead and enable gdb (leaving it at version 6.8). We probably won’t use it, but it won’t hurt to have it. Leave this screen.

All done configuring

We don’t need to mess with anything else, so hit Esc twice and you will be asked if you want to save your new configuration. Hit enter, and you’re ready to build your toolchain!

Type:

./ct-ng build

crosstool-NG will update you on the status of your build as it keeps going on, but for now you can sit back and relax. If you’d like, skip ahead and start downloading some of the other stuff you will need to have as you progress further through these instructions. Depending on the speed of your computer, this compilation might take 15 minutes to an hour.

If all goes well, crosstool-NG will finish by saying “Finishing installation (may take a few seconds)…” followed by a shell prompt. At this point, your cross toolchain is complete! Assuming you left it to be installed at the default location, you can now compile programs for the chumby by using:
~/x-tools/arm-chumby-linux-gnueabi/bin/arm-chumby-linux-gnueabi-gcc

I made a quick test app:

chumbytest.c:

#include <stdio.h>

int main(int argc, char *argv[])
{
    printf("It works!\n");
}

compiled it:

~/x-tools/arm-chumby-linux-gnueabi/bin/arm-chumby-linux-gnueabi-gcc chumbytest.c -o chumbytest

and transferred it to the chumby with scp to make sure it worked before advancing any further (assuming ssh has been enabled on the chumby):

scp chumbytest root@MyChumbysName.local:/tmp

to run it on the chumby over ssh:

ssh root@MyChumbysName.local
/tmp/chumbytest
exit

As long as it worked as expected, you’re ready to start working on getting Qt compiled. Well, kind of.

tslib

We need to do one prerequisite in order to get the touchscreen working, and it’s a library called tslib. Download it and extract it.

Start out inside the tslib directory and type:

./autogen.sh

Let’s go ahead and add our cross compiler to our path:

export PATH=~/x-tools/arm-chumby-linux-gnueabi/bin:$PATH

Now we’re ready to configure tslib to be cross compiled, and we’re going to tell it to install itself into a temporary directory inside our current directory. There are two hacks we have to do here–the first is we define a variable ac_cv_func_malloc_0_nonnull to be yes to avoid a compile error, and we also add -U_FORTIFY_SOURCE to the CFLAGS to avoid other errors, the same way we had to during the compilation of eglibc. Here’s the complete command:

ac_cv_func_malloc_0_nonnull=yes ./configure --prefix=$PWD/tslib --host=arm-chumby-linux-gnueabi CFLAGS=-U_FORTIFY_SOURCE

Compile it:

make -j 2 (or 4 or 8 or whatever, depending on how many cores you have)

Install it:

make install

Now there should be a tslib subdirectory inside the tslib directory, containing the compiled library, plugins, and a config file in etc. We really need to put the tslib library and include files into the appropriate place in our cross compiler’s sysroot so we can use it when compiling. Type:

sudo cp -R tslib/lib/* ~/x-tools/arm-chumby-linux-gnueabi/arm-chumby-linux-gnueabi/sysroot/usr/lib

to copy all the libraries into the cross compiler. We should also copy the include files in there:

sudo cp tslib/include/tslib.h ~/x-tools/arm-chumby-linux-gnueabi/arm-chumby-linux-gnueabi/sysroot/usr/include

This will simply make it easier in the future when compiling, so we don’t have to specify where the libraries are located. Now, let’s get the touchscreen working on the chumby before we compile Qt. Transfer the compiled tslib subdirectory to the chumby’s storage:

tar -cf - tslib | ssh root@MyChumbysName.local tar -xf - -C /mnt/storage

Now we need to get a shell into the chumby, quit the chumby control panel, and set up a few environment variables so we can calibrate the touchscreen:

ssh root@MyChumbysName.local
/usr/chumby/scripts/stop_control_panel
export LD_LIBRARY_PATH=/mnt/storage/tslib/lib:$LD_LIBRARY_PATH
export TSLIB_TSDEVICE=/dev/input/by-id/soc-noserial-event-ts
export TSLIB_CALIBFILE=/mnt/storage/tslib/etc/pointercal
export TSLIB_CONFFILE=/mnt/storage/tslib/etc/ts.conf
export TSLIB_PLUGINDIR=/mnt/storage/tslib/lib/ts

Edit /mnt/storage/tslib/etc/ts.conf and uncomment the “module_raw input” line.

You’re now ready to calibrate the touchscreen! Type:

/mnt/storage/tslib/bin/ts_calibrate

If all goes well, you should see “TSLIB calibration utility” and “Touch crosshair to calibrate” appear on the screen. Touch the crosshair for each corner and then the center, and the app will exit (the screen will stay the same, though). Now you’re calibrated! Test it by typing:

/mnt/storage/tslib/bin/ts_test

You should be able to drag the crosshair around on the screen. Hit ctrl-C to exit.

OK, so your touchscreen setup is now complete. You know all of those export commands you just typed before calibrating? You may want to put them into a file somewhere so they can be sourced whenever you need to run them. Whenever you want to use the touchscreen, those environment variables need to be set that way. We are now finally ready to compile Qt.

Qt

Here we go! The exciting part has arrived. We are ready to compile Qt. First, you need to download the latest source code for Qt. Pick the LGPL version unless you have a commercial license. Note that these instructions are based on version 4.7.2. Once you’ve downloaded the tarball, extract it and enter its directory. We now need to set up a Qt spec for the chumby.

Spec

Inside the mkspecs directory is a list of other directories containing specs for many different architectures. There is also a directory called “qws”. We want to use a qws spec, because our Qt will be drawing directly to the frame buffer device without having to have a window server like X11 installed. Instead, Qt will be its own window server. In the qws directory, there is a spec called linux-arm-gnueabi-g++. This one is very similar to the toolchain we are using, so let’s go ahead and duplicate it:

cd mkspecs/qws
cp -R linux-arm-gnueabi-g++ linux-arm-chumby-gnueabi-g++

Now, you need to edit the qmake.conf file inside of our new linux-arm-chumby-gnueabi-g++ directory. You will see several references to tools prefixed with “arm-none-linux-gnueabi-“. You should replace this prefix with the prefix for your toolchain. In fact, I would put the full path to each of these tools. For example, change arm-none-linux-gnueabi-gcc to /home/yourname/x-tools/arm-chumby-linux-gnueabi-gcc, and so on. It may seem stupid because you could always add the directory to your path, but when we’re executing the cross compiler from inside of Qt Creator, it will be easier if the full path is already there. Once you’re done with this, save the file and we’re ready to go!

Compiling

Here is the complete command, along with descriptions of what every option does below it:

./configure -opensource -embedded arm -xplatform qws/linux-arm-chumby-gnueabi-g++ -no-feature-cursor -qt-mouse-tslib -nomake examples -nomake demos

-opensource: specify that we’re using the LGPL. If you have a commercial license you should change this.
-embedded arm: specify that we’re compiling Qt/Embedded for ARM.
-xplatform qws/linux-arm-chumby-gnueabi-g++: specify the make spec that will be used for compiling. This tells Qt where our cross compiler is, and info about the cross compiled system.
-no-feature-cursor: hides the cursor, since it doesn’t make much sense to have one with a touchscreen. If you want a cursor, you can remove this option.
-qt-mouse-tslib: tells Qt to use tslib for its mouse driver
-nomake examples: Tells Qt to skip the examples. I already know how to use Qt so I don’t need a bunch of examples compiled. If you want them, keep it there.
-nomake demos: Same as above.

There are other options you can use to turn off specific features. If you don’t envision ever using WebKit, you can turn it off (-no-webkit). Anyway, type the command above, and you’ll have to agree to the open source license. Once that’s done, it’ll take a few minutes to configure the build. When the configure is complete, type:

make -j 2 (or whatever number of cores you have available)

Once that’s done (and it’ll be a while, trust me on this one!) you can install the libraries by typing:

sudo make install

The reason you need sudo is that Qt defaults to installing in /usr/local/Trolltech. You can change this with the -prefix option on the configure script, but I don’t mind Qt residing there. Once that’s done, you should have a functional Qt. Send the Qt libraries over to the chumby:

cd /usr/local/Trolltech/QtEmbedded-4.7.2-arm/
tar -cf - lib | ssh root@MyChumbysName.local tar -xf - -C /mnt/storage

And now Qt should be on the chumby’s SD card, with its libraries stored in /mnt/storage/lib. We can’t test it until we make a quick Qt app, though, so let’s install the Qt SDK.

Qt SDK

The Qt SDK is a massive download, currently in beta, but it works just fine. We’re going to install it and use it to create a test app to make sure Qt works. First, download the SDK from the Qt download site. I downloaded the Qt SDK 1.1 Beta online installer for Linux 64-bit from here (since my development machine is 64-bit). Make it executable and run it:

chmod +x Qt_SDK_Lin64_online_v1_1_beta_en.run
./Qt_SDK_Lin64_online_v1_1_beta_en.run

At this point, you’ll need to wait for it to finish “Retrieving information from remote installation sources…”. Once that’s done, accept the defaults, allow it to install in ~/QtSDK or wherever else you want it, and eventually you’ll have to wait for it to finish downloading and installing the SDK. Once it’s done, go ahead and allow it to Launch Qt Creator, but uncheck Open Qt SDK ReadMe.

After a few moments, Qt Creator will pop up. We now need to add our cross toolchain so that Qt Creator knows about it.

Adding the cross toolchain

Click on Tools, and choose Options. On the left, click Qt4. You should see a list of available Qt versions. We are going to add a new one, so click the blue + on the right side of the window. Where it says <specify a name>, type “Chumby Qt”, and where it says <specify a qmake location>, click Browse… and navigate to your cross compiled Qt’s qmake binary (/usr/local/Trolltech/QtEmbedded-4.7.2-arm/bin/qmake). Below, it should say “Found Qt version 4.7.2, using mkspec qws/linux-arm-chumby-gnueabi-g++ (Desktop)”. It’s inaccurate in claiming that this is a desktop target, but it’s ok — it still works. Click OK to save your new Qt version.

Creating a test app

I didn’t want to turn this into a tutorial on how to use Qt, but I at least want to walk you through creating a basic app, cross compiling it, getting it onto the chumby, and running it. Click on File and choose New File or Project…. Leave Qt Gui Application highlighted and click Choose…. Name your project TestChumbyQt and save it wherever you’d like. When it asks you to set up targets, uncheck all the targets except for the Chumby Qt target we created earlier. Click Next and leave the QMainWindow class name alone (MainWindow is fine for this example). Accept all the default choices.

Now we are ready to create the test app. Expand the Forms folder on the left and open mainwindow.ui. Click on the background of the newly-created window. Next, on the right side, there should be a “geometry” property. Click the + to expand it. Change width to 200 and height to 150. This should shrink the window a bit. On the left, drag a push button onto the main window. You can resize it to make it easier to press if you’d like.

Compiling the test app

Ok, we’re ready to compile the app. Go to Build and choose Build Project “TestChumbyQt”. If it asks you to save, click Save All. You should see a progress bar on the left side and eventually it will turn green, meaning the compile succeeded.

We’re ready to go. I put my test app in ~/Documents, so your command may be slightly different from mine:

scp ~/Documents/TestChumbyQt-build-desktop/TestChumbyQt root@MyChumbysName.local:/mnt/storage

Environment variables

Now, we need to define a few environment variables in order for Qt to work. You will need to do all of the exports we did above when we were testing out tslib, so if you still have that shell open you can skip doing those again. I’m listing them again just in case, though, plus some extras you need to do regardless.

export LD_LIBRARY_PATH=/mnt/storage/tslib/lib:$LD_LIBRARY_PATH
export TSLIB_TSDEVICE=/dev/input/by-id/soc-noserial-event-ts
export TSLIB_CALIBFILE=/mnt/storage/tslib/etc/pointercal
export TSLIB_CONFFILE=/mnt/storage/tslib/etc/ts.conf
export TSLIB_PLUGINDIR=/mnt/storage/tslib/lib/ts

And the ones you need to do:

export QWS_DISPLAY="LinuxFb:mmWidth80:mmHeight52"
export QT_QWS_FONTDIR=/mnt/storage/lib/fonts
export QWS_MOUSE_PROTO=tslib

The QWS_DISPLAY variable tells Qt about the physical dimensions of the chumby’s screen in millimeters. I did a very crude measurement with a ruler. If you don’t specify it, all the text will appear tiny because we’re working on a small screen. QT_QWS_FONTDIR tells Qt where to look for its fonts. Because it thinks it’s stored in /usr/local/Trolltech, we need to specify this so it knows where it should actually look. Finally, QWS_MOUSE_PROTO tells Qt to use tslib rather than the generic Linux input system.

As I said earlier, you will want to make a file you can source that includes all of these environment variable definitions — they are necessary in order to start a Qt app. Notice I didn’t add /mnt/storage/lib (where we put the Qt libraries) to LD_LIBRARY_PATH — the reason I didn’t is because the chumby already has that directory in its pre-supplied LD_LIBRARY_PATH, so I didn’t want to put it in there twice.

Running the test app

We’re ready to go now. In an SSH session to the chumby, type:

/mnt/storage/TestChumbyQt -qws

(-qws tells TestChumbyQt to be a window server. If you run other apps while it’s running, you don’t want to pass -qws to them–only one app should be the window server.) You may see an error about being unable to open /etc/pointercal, but that’s okay–our environment variable tells it to look elsewhere anyway. If all goes well, your window should appear on the chumby’s screen. Try pressing the button and dragging the window around. Everything should work! You can quit the app by pressing control-C in the terminal, or tapping the X in the upper right corner of the window.

Congratulations, you now have Qt working on the chumby. There are ways to get a Qt app to run at bootup now rather than the flash-based GUI, but that’s beyond the scope of this document. All that’s important is now you know how to run Qt apps.

All done

Unfortunately, I just don’t have the bandwidth necessary to host any binaries or source code for this. However, I have (hopefully) provided you with all the info you’ll need to create the libraries yourself. I have not yet figured out how to make a Windows-based toolchain for this — I know how to create the ARM cross compiler for Windows, but I just don’t know how to get Qt to compile inside of Windows. If I ever discover how, I’ll make another post about it. So for now, you will need a Linux environment for your development.

I know some of what I did was a little crude — I should have specified the ultimate destination directory for tslib when I configured it with –prefix, and I also probably could have specified in the configure script some of the paths that I had to redefine with environment variables, but this works for now. There’s nothing special about /mnt/storage, by the way — I just picked it because it was easy to put stuff there. It might be better suited for a special directory in /usr or something along those lines.

If you run into any problems, feel free to leave a comment and I’ll try to figure out what’s wrong. Enjoy!

Trackback

31 comments

  1. Hi Doug,

    thanks for the very useful howto. Unfortunately I hit a snag trying to compile qt (4.8.2). Configure dies saying:

    The tslib functionality test failed!
    You might need to modify the include and library search paths by editing
    QMAKE_INCDIR and QMAKE_LIBDIR in
    /home/nico/chumby/build/qt-everywhere-opensource-src-4.8.2/mkspecs/qws/linux-arm-chumby-gnueabi-g++.

    I tried adding QMAKE_INCDIR and QMAKE_LIBDIR and making them point to the lib and include dirs in x-tools where copied the tslib includes and libs as directed above but that doesn’t seem to be enough. Any tips?

  2. Hi Nico,

    I just went through the beginning of the tutorial on Ubuntu 12.04 and Qt 4.8.2 to make sure everything’s still OK. I did run into a few snags because of the age of my tutorial (gdb download problems with the older version of crosstool-NG, Ubuntu not including gawk by default, problem at the end of the crosstool cleanup stage with strip [probably fixed in a newer crosstool-NG]), but the tslib functionality test should still work without needing to modify QMAKE_INCDIR and QMAKE_LIBDIR assuming you have put the libraries and header files into x-tools/arm-chumby-linux-gnueabi/arm-chumby-linux-gnueabi/sysroot/usr/{lib and include}.

    I did mistakenly type the path of my newly-generated compiler into qmake.conf in the mkspecs/qws/linux-arm-chumby-gnueabi-g++ directory the first time I tried, and that can cause the error. My guess is that the configure script is not finding your compiler.

    The best thing to do would be to add -v to your Qt configure flags. It will print out all of the compiler output as it’s checking for things on your system and should help you figure out what’s going on. You will see a lot of errors that you don’t have to worry about (trouble finding other libraries that you don’t have that don’t matter), but once it gets to the tslib test failure, it should show you what failed when it tried to compile a test program that links against tslib. In my case the problem was that I mistyped the path to my new compiler, so it was not correctly calling my cross compiler. From what I can tell, if the cross compiler is not working or not being called correctly, the first place the configure script will bail out and say an error occurred is during that tslib functionality test. So it’s probably not actually a tslib problem, but rather a problem with the configure script finding the compiler.

    Hope this helps…let me know how it goes!

  3. Doh, you are right. The problem wasn’t in tslib at all. I also mistyped the path to the compiler 🙂

    Thanks for your very quick reply.

    Nico

  4. Glad you got it figured out! 🙂

  5. Sorry to comment off topic but I can’t seem to find any other contact info on your blog. I’m in some desperate need of some cross-compiling help. The toolchain that chumby.com provides has zero documentation so I’m wondering if building my own would maybe be better.

    I’m trying to cross compile MPD for my infocast 3.5″ (same as Chumby One for all intents) and have been pulling my hair out.

    If you could email me I’d be very grateful.
    PS More info about my current progress is over at the chumby forums here http://forum.chumby.com/viewtopic.php?pid=43033#p43033

    I know this is possible because someone did it but they never posted the binaries. Of course the guy who did it was a dev for MPD…

  6. Hi James,

    I don’t think the problem is with the Chumby toolchain, so building a new toolchain probably won’t help you. The real problem is that the Makefile is adding “-I/usr/include” and similar lines to your CFLAGS. This causes the compilation to grab header files from your build computer rather than the chumby toolchain.

    It looks like the final culprit that causes a compiler failure in this case is the FD_ZERO macro. FD_ZERO is used for clearing a list of file descriptors that eventually get passed to select(). It appears FD_ZERO must be defined using extended inline assembly in your computer’s include files, probably for efficiency’s sake. One of the constraints it uses for an input or output parameter must not be a valid constraint that GCC defines for the ARM architecture. Even if it was, the actual instruction(s) in the inline assembly statement would be incompatible. But all that is just a technical “why”. To make it simple, it’s trying to mix ARM and (your build system)’s assembly together due to the wrong -I flags being passed to GCC.

    My initial guess is the configure script is using pkgconfig to find other libraries that mpd depends on, and pkgconfig is finding your local system’s version of those libraries rather than ARM versions of them, and thus including a bunch of stuff belonging to your build system rather than to the chumby system.

    Cross-compiling software that uses pkgconfig is kind of tricky. I’ve done it before, but it can be annoying because you need all of your package’s dependencies first, and you have to instruct pkgconfig to ignore everything in /usr. As I recall, the trick is to redefine the environment variable PKG_CONFIG_LIBDIR to not include /usr/lib/pkgconfig, but instead to include your target system’s usr/lib/pkgconfig so it will find all of your target libraries.

    If you look at the INSTALL file included with mpd, you will see that it requires at least one of the listed input dependencies, and one of the listed output dependencies. If Chumby already has these, you will probably want to manually specify the locations of their libraries and header files using options passed to the configure script instead of using pkgconfig. In fact, if you could find a way to disable pkgconfig completely, that would probably work best. The trick may be that you will need to build some of the other dependencies first–I don’t know if Chumby provides dev versions of those libraries with header files or not. If they do, you should be able to just copy them over from the Chumby to your build system. If they don’t, you’ll probably have to cross-compile some of those dependencies first.

    Anyway, that’s a general idea of how I would attack this problem…

  7. Thanks for the reply Doug. After I had posted this question I starting thinking about this a little differently and realized a few of my initial assumptions were wrong. First the guy who had successfully compiled MPD for the Chumby said he had compiled MPD + ffmpeg and used ALSA as the output. I had misread ffmpeg as ffdshow for some reason. When I initially tried to run the ./configure for MPD a ton of libraries were missing for playing various filetypes so I grabbed the dev packages for each. After getting at least a little more familiar with the process I reread the other user’s MPD post and realized he was saying he just compiled MPD with the ffmpeg library and chose ALSA as the output.

    From what I gather all of the libraries I grabbed were x86 anyway and would also need to be cross compiled I’m going to try to compile it right on the chumby itself instead and see what happens. If I only have to compile ffmpeg on the device (aside from MPD) it shouldn’t be too bad. That being said once I get it working I would like to go back and figure it out using the cross compiling method so I know how to do it in the future. I’m somewhat new to linux, I have a hacked pogoplug serving as my torrent downloader and dnla server so I’ve got my feet a little wet already but have so much to learn. I’m using these little devices as a motivator to experiment and learn more, problem is sometimes documentation is lacking and I wind up not even knowing what it is I don’t know if that makes sense 🙂

    Just so I’m clear, if I were to fix the -I /usr/include part and it did rely on the chumby toolchain instead what happens for libraries I’d need like ffmpeg? Is the toolchain smart enough to grab my x86 ones and cross compile them as well?

    Thanks again for the reply!

    Anyway thanks for the info, I’ll be coming back to it

  8. Hey, no problem! OK — so to reproduce what he did, you’re going to need ffmpeg and ALSA.

    When you say you “grabbed the dev packages”, do you mean you installed the packages named “libwhatever-dev” in Ubuntu (or the equivalent idea on another distribution)? That would install the header files and development libraries for your local machine, but those (particularly the libraries) are platform-specific (x86-only) as you figured out. Instead, you would have to download the source code for those libraries and cross-compile them, unless you can figure out how to grab the development libraries and headers from Chumby (I’m not sure if they provide them or not).

    I would agree trying to compile them directly on the Chumby would be easier. It’ll take a long time, though. My only concern is whether the relevant header files and development libraries for ALSA and ffmpeg are already on the Chumby. If they aren’t there, you will still have problems compiling directly on the Chumby. I don’t know the answer to that for sure…

    I know what you mean about documentation lacking. 🙂 It’s just one of those things that you have to play around with. Cross compiling isn’t really a science–every package is different, and sometimes you have to do weird voodoo to various scripts to make them work correctly when cross-compiling. Google is my best friend in situations like that. It’s a ton easier if you compile directly on the host you’re planning to use instead of cross-compiling, but the tradeoff is how long it takes to compile on a slower processor. In the context of this post, for example, Qt would be ridiculous to compile directly on the Chumby. It’s a humongous library that already takes a long time to build on my Core i7 machine.

    If you fixed the -I/usr/include stuff, you would still run into problems. First of all, it would fail when it was looking for ffmpeg/ALSA header files because the toolchain probably doesn’t have them. If somehow you had the headers or obtained them from somewhere, it would then probably fail during linking because it wouldn’t find the libraries to link against. The toolchain is not smart enough to grab your x86 libraries and cross-compile them–in fact, it doesn’t really have the ability to do that because the -dev packages don’t include source code for the libraries–just pre-compiled libraries and header files. You have to grab the source and compile it yourself, or find ones that someone else has already compiled. Then, in the configure script, you can point mpd to where it needs to look for the include files and libraries for ffmpeg and ALSA. Just a warning–I believe I have gone through cross compiling ALSA in the past and it wasn’t very much fun…I would definitely recommend looking into compiling this stuff directly on the Chumby. 🙂

  9. One more thing…I suppose if you could get ahold of the header files (if the Chumby doesn’t already have them in /usr/include) for ALSA and ffmpeg, you could copy the ALSA and ffmpeg libraries off of the chumby (if it already has them, in /usr/lib) and put them on your computer somewhere. Then, you just would have to point the mpd configure script to the pre-existing ALSA and ffmpeg libraries (there will be options you can give the configure script — run it with –help to see them all), and it would probably be able to link against them that way.

  10. Ok so I’ve got the toolchain installed on the infocast (we’ll just refer to it as a chumby from here out though since software wise I believe they are identical and use the same processor etc).

    I downloaded the MPD source and when I try to configure it I get an error that Glib 2.12 is required. Ok, that’s fine, I was expecting to have to compile some dependencies on the Chumby. Maybe this is a stupid question but when I’m compiling these dependencies and later on the libraries I’m not sure how and when I’m supposed to specify directories.

    The Chumby doesn’t have much room on its root partition but it has ~400MB on /mnt/storage. Others have suggested that once I get to the point of compiling MPD I should specify the directory as /mnt/usb however I’m not sure what that means for the libraries etc.

    First things first, when I compile Glib 2.12 where to I put it afterwards? Same thing later with ALSA etc?

    Like I said I’m new to this so bear with me 🙂

  11. Sounds good — I’ve been kind of making that naming assumption about Chumby vs. Infocast all along 🙂

    OK, so after you said that, I booted up my Chumby One. It indeed doesn’t appear to have Glib or ALSA installed, so you are definitely going to have to compile them.

    I see what you’re saying about how the root partition doesn’t have any space. Specifying where a package will be installed might be different for various packages, but most packages that use configure scripts follow a very standard scheme. That scheme is the --prefix=/path/to/install parameter to the configure script. Most packages default to installing with a prefix of /usr/local. This would cause the programs to be installed in /usr/local/bin, libraries into /usr/local/lib, and header files into /usr/local/include. Clearly with the limited space of the root partition, this isn’t an option in your case. If you specify a prefix of /mnt/storage, or /mnt/usb, it will install the libraries into the lib and include subdirectories of the prefix you pick. Example: ./configure --prefix=/mnt/usb

    Other packages might differ slightly in how this is done, but in general, things like Glib and ALSA will probably adhere to the --prefix option. You can always do ./configure --help to get a list of options.

    After you run ./configure and make, typing make install will install all of the necessary files to the prefix you chose earlier. That’s generally the pattern you will follow while compiling all of the dependencies of mpd, and then finally the same pattern you will follow when mpd finally succeeds at compiling.

    After installing a dependency, you may have to tell the configure script of the library depending on it (for example, mpd depending on Glib) to look in /mnt/usb instead of /usr for the library. That’s usually a configure script option to tell it where to find a particular library dependency. It will vary based on every package — look at the ./configure --help output for more on that.

  12. First off thank you so much for the lengthy and detailed replies it is greatly appreciated and very easy to understand!

    Unfortunately my head is about to explode 🙂 Initially when I tried to run the ./configure for MPD it said I needed GLib as I said. So I got the source for GLib and when I tried to run ./configure on it I it said I needed pkg-config. Ok this might take awhile but I’m determined, I download the source for pkg-config and here’s the kicker, when I run config for pkg-config I get an error saying pkg-config and glib-2.0 not found. How is pkg-config dependent on pkg-config lol?

    The output from configuring pkg-config was pretty long but here is the tail end of it with the errors at the bottom:

    checking whether the gcc linker (/mnt/storage/gcc/usr/arm-angstrom-linux-gnueabi/bin/ld) supports shared libraries... yes
    checking whether -lc should be explicitly linked in... no
    checking dynamic linker characteristics... GNU/Linux ld.so
    checking how to hardcode library paths into programs... immediate
    checking whether stripping libraries is possible... yes
    checking if libtool supports shared libraries... yes
    checking whether to build shared libraries... yes
    checking whether to build static libraries... yes
    configure: creating ./config.lt
    config.lt: creating libtool
    checking for gcc... (cached) gcc
    checking whether we are using the GNU C compiler... (cached) yes
    checking whether gcc accepts -g... (cached) yes
    checking for gcc option to accept ISO C89... (cached) none needed
    checking dependency style of gcc... (cached) gcc3
    checking for default search path for .pc files... ${libdir}/pkgconfig:${datadir}/pkgconfig
    checking for --with-system-include-path... /usr/include
    checking for --with-system-library-path... /usr/lib
    checking whether to list both direct and indirect dependencies... no
    checking for Win32... no
    checking for pkg-config... no
    ./configure: line 13540: --exists: command not found
    configure: error: pkg-config and glib-2.0 not found, please set GLIB_CFLAGS and GLIB_LIBS to the correct values

  13. Oops, I’ve been posting too much in BBcode based forums and used the wrong code
    Just checking if this works for next time

  14. Hey James,

    (I went ahead and fixed your original comment’s code tag for you)

    After a bit of Googling, it seems you’re running into a weird, weird problem…pkg-config and glib depend on each other for some reason. pkg-config depends on glib and glib depends on pkg-config. Something’s gotta give, though — there must be an alternate way to compile one of them in a way that doesn’t depend on the other. I’m not sure exactly how to get around it, but it’s not your fault — it looks like something other people have run into as well. You might be able to do some Googling and see how others have gotten around that particular problem.

  15. Sorry I meant to update my post earlier but it looks like I never hit submit. Anyway I noticed on the pkg-config webpage it mentioned that versions 0.24 and lower included GLib 1.2.0 so I tried that instead and was able to make and install it. I tried going back and compiling GLib 2.12 again since that is what the ./configure for MPD needs (not even at the ALSA or ffmpeg stage yet) and found GLib 2.12 also needs gettext so I got the source for that. Its huge, after uncompressing the tar its over 100MB and I don’t have too much room to play with in my /mnt/storage directory. Running ./configure on gettext took almost an hour. I’m running MAKE right now and will probably have to leave it over-night. This is fun yet extremely frustrating at the same time 🙂

    Just out of curiosity, regarding cross compiling on my Ubuntu machine should I ever be fool enough to wish to cross compile another program, how would I do the following:

    a) Prevent the program’s ./configure script from finding x86 libraries and force it to check a different /lib and /include directory? When I installed the toolchain I had to create a directory /usr/arm-linux which I believe has these folders in it and it would stand to reason that they would have the same libraries etc that the chumby has correct?

    b) Cross compile whatever missing dependencies and place them such that the ./configure would find them? Assuming the above “a” question is answered would I simply specify –prefix=/usr/arm-linux when compiling them initially?

    You have no idea how much of a help you’ve been, I really appreciate it and hopefully after all is said and done (assuming I have success) I can use my experience to put together a good tutorial for others like me!

  16. Hey, no problem!

    Oh, ok — very nice! I’m glad you got pkg-config installed and figured out. I was worried about GLib just because it is a huge library with lots of dependencies. I hope you don’t get bogged down with tons of dependencies.

    Answer to question a:

    When you run ./configure with the --host=... option, it will usually generate a Makefile that doesn’t ever explicitly add -I/usr/include to the CFLAGS. The toolchain automatically knows where to find its own usr/include folder without being told, but for some reason, the package you were cross-compiling decided to add -I/usr/include to your CFLAGS. I believe that pkg-config was the culprit for this — pkg-config was looking at your host’s /usr/lib/pkgconfig directory because it automatically does that. It found one of the dependencies it was looking for, but pkg-config is rather unintelligent when it comes to cross compiling, so it found your host’s version of a dependency and grabbed info from the .pc file, probably adding -I/usr/include to its flags at that point. When you cross-compile things with pkg-config, I believe you need to define the environment variable PKG_CONFIG_LIBDIR to point to your new prefix, in order to get it to ignore your host’s libraries and look at your collection of newly-compiled things.

    The toolchain doesn’t necessarily include all of the Chumby’s libraries — this is another annoyance. Usually somewhere nested in your toolchain directory there is a lib and include directory where some libraries/header files included with the toolchain are stored. You can usually put other libraries/header files (copied from the Chumby, or cross-compiled by you) into those directories to add them to your toolchain if you want. Other than that, you can change CFLAGS and LDFLAGS to tell the compiler and linker where to find your cross-compiled or copied libraries.

    Answer to b:

    In general, I believe you can make these things work with a few simple rules. You would start by deciding on a directory to install to. For simplicity, it would help if it was named the same on both your computer and the Chumby, so if you were installing to /mnt/usb, you would make a directory /mnt/usb on your computer. Next, we know that pkgconfig files are usually stored in the pkgconfig directory inside the lib directory, so I would define PKG_CONFIG_LIBDIR and export it (remember, you have to redo this command any time you open a new shell): export PKG_CONFIG_LIBDIR=/mnt/usb/lib/pkgconfig

    Now, if you tried to set up GLib: ./configure --host=arm-linux --prefix=/mnt/usb the configure script would probably bail out at this point because it couldn’t find gettext. If it didn’t fail, it would mean that it’s somehow finding your host’s version of gettext, even though it shouldn’t. When you run into a problem like that, sometimes you have to just recognize what’s going on and manually build your target version of the library. I know this is convoluted, but cross compiling ain’t easy 🙂 So you could install gettext with the exact same ./configure line, and hopefully it would install itself into /mnt/usb on your cross compiling computer. Now if you ran GLib’s configure script again, it would hopefully pick up gettext’s location.

    Sometimes, packages don’t use pkg-config, and thus don’t know where to automatically look for a dependency. In that case, you generally have to include the path to their header files and libraries in your CFLAGS and LDFLAGS: export CFLAGS=-I/mnt/usb/include
    export LDFLAGS=-L/mnt/usb/lib
    . If that doesn’t work, there are sometimes options that various configure scripts take for manually specifying the path to a particular dependency.

    Whew! That’s kind of a start. But there’s no real rule that works 100% of the time. Sometimes you just have to cheat and do something ugly like hack the Makefile or the configure script to bypass somebody’s automated test that just plain doesn’t work when cross compiling. This kind of situation is becoming rarer and rarer — most packages I see nowadays support cross compiling — but it can still happen.

  17. Doug this is great info and things are starting to make more and more sense! A brief update for compiling directly on the Chumby, good news I compiled gettext which let me compile Glib2.12 and now if I run just ./confige –prefix=/mnt/storage for MPD without specifying any other options it finishes clean and I could make it. Now I have to add the options of course 🙂

    Back to the cross compiling though, one thing I’m still confused about and that is the lib locations. So the toolchain has its own lib and include directories but you’re also talking about pointing pkg-config to /mnt/usb (which I created on the ubuntu machine) so if I am to copy all of the libraries etc from my Chumby do I put them in /mnt/usb or in the toolchain location?

    Dude I seriously owe you a beer, at some point you’ll have to email me your paypal address and I’ll make an inebriation donation 🙂

  18. So I decided while my Chumby is busy compiling away I’d try what you suggested for cross compiling. I followed your instructions and after running configure for MPD I got the same GLib2.12 needed message as I did on the Chumby, this is good. I downloaded the source for GLib and tried to configure it, expecting to see the need for pkg-config. Instead I get:

    checking for growing stack pointer... configure: error: cannot run test program while cross compiling.
    See 'config.log' for more details

    The config.log might be over my head but right off the bat its showing the uname stuff for my ubuntu machine and when its checking for a bsd-compatible install the result is /usr/bin/install -c. Later on in the log it does seem to be looking for /usr/bin/arm-linux so maybe that gets straightened out later in the process.

    Baby steps I guess 🙂

  19. Ah, yes. In my last comment, I said “Sometimes you just have to cheat and do something ugly like hack the Makefile or the configure script to bypass somebody’s automated test that just plain doesn’t work when cross compiling.” This is one of those cases, kind of. The problem is that it needs to run a program to determine whether the stack pointer gets bigger or smaller as you add things to the stack. It can’t determine that automatically without running a program — but since you’re cross compiling, you can’t run the program. Apparently there are a few things like this that happen when compiling GLib. The trick is to tell it ahead of time the answers to the questions.

    Here’s a good reference for how to cross compile GLib:
    http://wiki.beyondlogic.org/index.php/Cross_Compiling_USBIP_for_ARM#glib

    If you Google for that error, you’ll also find other people explaining what’s going on — but they’ll pretty much say what I just said too 🙂

    I actually don’t think you will have to cross-compile pkg-config. pkg-config is mostly only used at build time for figuring out where other libraries are. Since your build machine (x86) already has pkg-config, everything will probably work OK with that setup.

    As far as your question in the post before, either option would work as long as you add /mnt/usb/lib to your LDFLAGS and /mnt/usb/include to your CFLAGS. You may not need to copy any libraries over — I wouldn’t bother until I found an error linking against a library (or finding a header file) that you know is already on your Chumby.

    No problem on all of this! I know I’ve been through this stuff before and it can be very frustrating. I’m hoping this can help other people in the future who find this via Google. Cross compiling really is voodoo. Some people prefer to use a virtual machine that pretends it is running natively on the platform you’re compiling for (so you can avoid the cross compiling stuff). Here’s another good link relevant to your GLib stuff describing what I mean:

    http://felipec.wordpress.com/2009/06/07/installing-scratchbox-1-and-2-for-arm-cross-compilation/

  20. Thanks Doug, I admit I guess I was getting a little too used to getting answers from you and forgot to consult google first 🙂 What you are saying makes perfect sense. Also thanks for the Scratchbox link, I’d been curious about that but wasn’t sure exactly what I needed to be looking for.

    BTW I just got my Raspberry Pi in the mail today, initially the Infocast/Chumby stuff was meant to tide me over until it arrived. Now it’s seeming like this stuff has taken over and it might be awhile before I get to my Pi lol.

  21. Haha, no worries!

    That’s great that you got your Raspberry Pi. I’m not on the waiting list yet, but I’m definitely planning on getting one whenever they end up being available! I have a couple of Chumby Ones and a Chumby 8 sitting around here that I’ve been meaning to customize too (I’m planning on making a complete firmware from scratch that no longer uses Chumby’s software at all and is completely Qt-based), but I always get tied up doing other stuff!

  22. Haha, other stuff like walking strangers through cross compiling 🙂

    I’m trying to install the sandbox as per the last link you gave, hopefully that will make things much easier. Meanwhile though I hit a snag with my on-chumby compiling.

    configure: error: ffmpeg decoder library: libavformat+libavcodec+libavutil not found

    I downloaded the source for ffmpeg and try to configure it but this is what it returns:

    chumby:/mnt/storage/ffmpegsource/ffmpeg-0.11.1# ./configure --prefix=/mnt/storag
    e
    ./configure: eval: line 1: 2..9946.asm: not found
    ./configure: eval: line 1: 2..9946.c: not found
    ./configure: eval: line 1: 2..9946.cpp: not found
    ./configure: eval: line 1: 2..9946: not found
    ./configure: eval: line 1: 2..9946.h: not found
    ./configure: eval: line 1: 2..9946.o: not found
    ./configure: eval: line 1: 2..9946.S: not found
    ./configure: eval: line 1: 2..9946.sh: not found
    ./configure: eval: line 1: 2..9946.ver: not found
    BusyBox v1.16.0 (2010-11-05 18:58:58 PDT) multi-call binary.

    Usage: chmod [-Rcvf] MODE[,MODE]... FILE...

    Each MODE is one or more of the letters ugoa, one of the
    symbols +-= and one or more of the letters rwxst

    Options:
    -R Recurse
    -c List changed files
    -v List all files
    -f Hide errors

    ./configure: line 2162: can't create : nonexistent directory
    ./configure: line 2609: can't create : nonexistent directory
    ./configure: line 2609: pr: not found
    gcc is unable to create an executable file.
    If gcc is a cross-compiler, use the --enable-cross-compile option.
    Only do this if you know what cross compiling means.
    C compiler test failed.

    If you think configure made a mistake, make sure you are using the latest
    version from Git. If the latest version fails, report the problem to the
    ffmpeg-user@ffmpeg.org mailing list or IRC #ffmpeg on irc.freenode.net.
    Include the log file "config.log" produced by configure as this will help
    solving the problem.

    Since I’m on the chumby it shouldn’t be cross-compiling should it? But then again the tool chain is GCC so that cc part looks suspiciously like it could stand for cross-compile.

    This time I googled first but what I’m seeing is a little confusing, first it seems like a lot of people are using this more for video which isn’t what I need. Secondly most of them really are cross-compiling it so I’m having issues figuring out what applies and what doesn’t.

    Hopefully the scratchbox route will help.

  23. 😀

    Hmm. It looks like ffmpeg’s configure script does things that busybox (the shell used by the Chumby) does not support. I don’t know what it is off the top of my head, but my guess is it ran some command that BusyBox didn’t like. You might have to cross compile ffmpeg on your x86 computer (which will have a more advanced shell like bash or dash) in order to get it to work (and then copy over all the files it installs over to the Chumby so you can continue compiling everything else directly on the Chumby)…I know that seems weird considering that usually everything works better on the target machine when you compile, but this looks like an exception. I guess another possibility would be to figure out which line in the configure script is causing all the weird errors and patching the configure script to skip that step (we already know your GCC can create executable files). That would be kind of ugly, but it could be done…

    It’s ok–the error it said about “If gcc is a cross-compiler” is just an error it puts up if it has trouble compiling a program. Something else in the configure script caused the error, but that was a generic warning it put up. “cc” doesn’t stand for cross compiler — it stands for C compiler 🙂

    OpenEmbedded would probably make everything much easier, honestly. I’m still pretty surprised that ffmpeg failed to compile directly on the host, but I guess it’s not too surprising considering BusyBox is a stripped-down shell. Maybe another possibility would be to get bash onto the Chumby…that might get kind of complicated though.

  24. One more thing, a guy replied to my thread over in the Chumby forums and just informed me that someone has already made OpenEmbedded recipes for MPD so that may be yet another route I need to look into.

    http://forum.chumby.com/viewtopic.php?pid=43086#p43086

  25. Hey Doug, thanks once again for the info. I didn’t get a chance to get back to this over the weekend. I’m going to look into the OE option but I’m also interested in the Scratchbox options. I was following the guide in the last link you’d posted, I installed it and then got to the part where he was setting up the Arm version and the compiler and realized he was setting it up for a different processor. The Chumby is an armv5 correct? What would I specify for the compiler and all the rest of the stuff?

    Here is what the guy has for arm7 stuff

    /opt/scratchbox/tools/bin/sb-conf setup armv7 --force --compiler="cs2007q3-glibc2.5-arm7" --devkits="qemu" --cputransp="qemu-arm-sb"
    /opt/scratchbox/tools/bin/sb-conf select armv7
    /opt/scratchbox/tools/bin/sb-conf install armv7 --clibrary --devkits --fakeroot --etc

    Thanks,
    James

  26. Nevermind about the SB config question, I found instructions on the Chumby Wiki here I swore I’d looked for this before but may have been searching for Infocast instead of Chumby.

  27. Hi James,

    Glad you figured it out. Yes, the Chumby (One) is an armv5 — it’s a Freescale i.MX233, which uses the ARM926EJ-S core, which belongs to the ARM9-E family, which is based on the armv5 architecture. Whew! 🙂

    Adrian,

    I’m glad my tutorial was able to help you! Have fun developing with Qt!

  28. Hi Doug,

    I would like to Thank you for the amazing and informative tutorial that you have share. After endless hours and hair pulling I managed to compile my first Qt App on Chumby. This opens a new door for opportunities and ideas.

    Thanks again!
    – Adrian

  29. Hey Doug, well I ran into some issues installing Scratchbox later too and I’m stumped again.

    I was following the instructions on the Chumby wiki for installing SB, which are partially broken (stable main doesn’t exist but apophis main works) but I got through that and hit a snag at installing the C-libraries to the target.

    As per the instructions:

    Create the new target

    You should be able to switch to the new toolchain now:

    Run sb-menu.
    Setup a new target. For this example, we named the target Chumby.
    Select the new compiler: arm-2009q1
    Select only the cputransp devkit.
    Choose an ARM emulator. The latest available version is qemu-arm-cvs-m.
    Do not select a rootstrap (select ).
    Install files. De-select all options except for /etc and C-library
    Select the new target, observe that it reloads the shell onto the new target:

    I get to “Install files. De-select all options except for /etc and C-library” and it gives me the error “Failed to install C-library to target:Chumby”

    Any ideas?

    I’m really sorry for all of the questions Doug and I really appreciate the answers, I just want to get one cross-compiling environment working and I’ll be happy 🙂

  30. Hey, don’t worry about it — it’s useful info for everyone in the world to see.

    I honestly don’t know much about Scratchbox (I’ve never used it before), so I’m kind of in the dark here, but I can say that it appears stable main works for me, unless you got a failure further down the line after trying to install scratchbox-core and scratchbox-libs. I’m in the middle of installing it now. I just did the command

    echo "deb http://scratchbox.org/debian/ stable main" >> /etc/apt/sources.list

    as root, stolen from the Scratchbox Wiki (link went bad; removed). The download is going pretty slowly, but it’s progressing. I’ll keep trying to install it as the Chumby Wiki states and I’ll see if I get anywhere…

    Edit: Nevermind, I see the problem — the scratchbox-devkit-cputransp package isn’t available in stable main. Hmm…

    Edit 2: According to this page (link went bad; removed), it says:

    Use scratchbox-qemu-devkit for the latest qemu instead of scratchbox-cputransp-devkit

    So I went ahead and installed scratchbox-devkit-qemu instead. We’ll see if that gets me anywhere.

  31. I ran into problems even earlier than you. I just don’t know how to do Scratchbox stuff, sorry…my experience is more with cross-compiling. I want to learn someday, but I have too many other things going on 🙂

Add your comment now