Yesterday, I wrote a blog post about setting up a development environment for a Nokia N900. I spent most of the day with family, enjoying some rough weather out on Cape Cod. However, it was windy and rainy outside and I did find some time to explore a little bit more in my effort to build QWaveClient for the Nokia N900.

Warning: The following content is very geeky. If you’re not a geek, skip to one of my other articles.

QWaveClient for Linux

The first step was to try and build QWaveClient for Linux. QWaveClient depends on ProtoBuf. The documentation says that it requires ProtoBuf 2.1 or higher. So, I tried with ProtoBuf 2.2 but I kept getting messages about mismatches between versions of ProtoBuf, so I rolled back to ProtoBuf 2.1 and got it to compile. One of my todos is to look into what it would take to get QWaveClient to compile cleanly for me with ProtoBuf 2.2

I should note that compiling ProtoBuf was a long arduous process. I am running on an old IBM Thinkpad R51 that core dumps frequently at random times when I try to compile. So, it took several tries, but eventually, I managed to compile ProtoBuf 2.1. On top of this, the install procedure did not move libprotobuf.so.4.0.0 into the /usr/lib directory and create a symbolic link, so I had to do that manually. However, once I completed that, I managed to get QWaveClient 0.2 Alpha compiled and working on my Linux box. It seems to misbehave a little bit more than 0.1 Alpha did, but that is because there is new functionality that seems to be not yet completely implemented.

I was concerned about whether I would need to update my FedOne server. It is a fairly early server running at changeset 122. Would the new functionality of the QWaveClient not work? Would it crash the server? It may be that some of the problems I had connecting with Google Wave Sandbox or with some of the new functionality with the QWaveClient were because of my old FedOne server, but all in all things worked quite nicely.

Development Tools For Maemo

The next issue was to try and find how to install the appropriate development tools for Maemo. The standard configuration has a compiler, but I could not get the compiler to properly compile ProtoBuf 2.1 in the ScratchBox. Each time, it would fail during the ‘make check’ phase, trying to build the libprotobuf.so.4.0.0 library. So, I set that part of the project aside, and started looking at another part. How could I get QT installed.

The initial instructions I tried suggested adding
"deb http://repository.maemo.org/extras-devel fremantle free non-free"
to the /etc/apt/sources.list, doing an apt-get update, and then an apt-get install qt4. I can’t find the instructions I was following so, I don’t recall exactly what the package they were recommending was, but I could not find the package.

So, I set this aside, until later, I found the Qt4Hildon page. It suggested getting the libqt4-gui and libqt4-dev packages, which should be in the available repositories. I managed to install them in both my X86 and ARMEL environments and started compiling a sample application.

First, I used the Qt Creator IDE to build a simple application in QT. This created the .pro file and I then ran qmake project1.pro and then make, and my project was compiled. I ran it under the X86 architecture and it displayed nicely on the Xwindow. I then compiled the same project in the ARMEL architecture and managed to get this to run, even though I cannot get the full N900 environment running in ARMEL emulation mode, due to problems with the DBUS and/or the Hildon environment. However, it occurred to me that my simple applications didn’t require either of these and should probably run. I was pleased to see that I was correct, and my application was up and running.

As I sat down to write this article, I made an attempt at compiling ProtoBuf in the ARMEL environment. I had only tried it in the X86 environment, and I was very pleased to find that it compiled. Like in my Ubuntu environment, it didn’t install the libprotobuf.so.4 library properly, so I did that by hand.

With the ProtoBuf libraries available and qmake working, I started compiling QWaveClient in the ARMEL environment. At one point, it complained about the use of qMax. I took out the function and simply took the arbitrary size. This is likely to result in a graphic being larger than necessary when and if I get QWaveClient to compile properly.

With the compilation complete, I attempted to run it and found that it was complaining about missing some phonon classes. Searching around I found that I needed to do an apt-get install libqt4-phonon. With the package installed, I started the application in the ARM emulation mode.

The first screen where you enter your login information came up properly. However, when I attempted to get into the QWaveClient itself, it started giving errors about not connecting to the D-BUS and getsockopt level=1 optname=17 not yet being supported. Qemu then aborted on a signal 6.

Trying to find a solution for this, I found a wiki page on the Maemo.org site that states:

The ARMEL target should not be used for application testing and just for cross compiling. The target is not meant to support this. Please use for any other use than cross-compiling the X86 target.

It was in a section explaining the errors I had been receiving, so I figured I’ve tested my package about as well as I can on the ARMEL target.

With this, I went back to the X86 target. I installed the extra packages I had discovered I needed are tried recompiling. Everything ran successfully and I now have the QWaveClient running in X86 mode in my development environment. I didn’t even have the qMax problem I had run into with my ARMEL compilation. I’ve tested the functionality and it works as about the same as in my Linux version. What is not in there is any of the Hildon functionality, so scrolling and selecting menu items does not work as nicely as it could.

So, I now have several todos. Upgrade my FedOne server. Recompile the ARMEL version again to see if the additional packages gets around the qMax problem I had. Add Hildon functionality. Package the client. Put it up on the testing distribution system, and hope that someone who has already gotten an N900 can give it a test and give me feedback.

If you’ve read all the way down to here, you probably are a hard core geek and I’d love to talk more about tests with QWaveClient and/or N900. Let me know what you’re up to.