Noobish Porting Questions

[Zeno Arrow]

Hi all.

Number of times in this forum I've seen people take a guess on how easy or hard a Linux app will be to port to the Pandora. I've been thinking about this, and other than the processing power requirements for certain apps, I can't see why the majority of Linux apps won't be very straightforward to get working. For those who know better please try not to cringe too hard whilst I explain why I think this...

Okay, so most Linux packages are designed to work on x86 processors, but with source code available we don't need ready made packages, we can compile from source, right? Packages are obviously nice to have but just trying to gauge how quickly we can get something working.

If a program is known to compile on an x86 version of GCC with certain flags set, will compiling on an ARM version of GCC (same version number) with the same flags be just as painless? If not, why not? I understand that different compilers won't always produce the same results, but if you use GCC on both platforms where's the problem?

I realise some programming languages are more portable than others (ASM obviously is out, but how many programs have ASM as part of their source code? Not many I'd be willing to wager). Let's say we were hoping to port a program written in C, for example. What affect does processor endianness have to play on the possibility of ports written in C? As far as I can see only numbers stored directly as pure binary would be affected.

There are issues I've missed out (such as the availability of libraries like Qt), but too summarise my rambling above, I'll ask this: What potential blocks are we likely to encounter when porting x86 Linux programs written in C to the Pandora? Thanks in advance for your advice.

 

[WolfpacKxx86]

Don't know that much about porting, but thought that this might help answer your question :
http://www.codejedi.com/cgi-bin/blog.cgi/2008/12/index.blog

 

[mali]

off topic
Very good pix to see the resolution differences of Gp2x and Pandora in real life

 

[Tor]

The easiest is probably to compare with the Nokia internet tablets. After all, they're 800x480 ARM OMAP devices with a slightly limited set of default libraries available.

And yes, it's often just as easy as the OP suggests.. just recompile. For non-graphical applications it's almost 100% true: Get the source, recompile, install and run. I've done that with lots of applications. For graphical applications it's a bit more complicated:

- A: Do you have the graphical libs available? For the Nokia the question would be: Does the app you want to recompile use GTK+ 2.x? If yes, it'll compile just fine, unless it also uses some other library that you don't have.. hunt it down, repeat. Often it'll be just fine.

- B: Does the application run well in 800x480? (or, for the Nokia UI, in slightly less - see C). If not, you will have to do some work. This can be little work, or a lot of work.

- C: On the Nokias, you also have to ask: Do you want to run it in full-screen? The general question is: Does your device have some unique, special version of the UI that needs some tweaking? The Nokias use a GTK+-based UI called Hildon, so to get everything integrated smoothly you'll have to add some additional Hildon variants of GTK+ calls, and replace others (e.g. the initial gtk window call should be a hildon window call).
But if your standard UI is a non-modified variant you don't have to do this step (which is the case for those running with a different window manager or KDE on their Nokias).

-D: For some complicated applications it can be more troublesome, for sometimes obscure reasons. A heavy application like AbiWord has had some people working on it for a long time.

 

[sterling976]

I agree with Tor, it's usually as simple as compiling against the proper architecture. The CodeSourcery tools are great for this.

The closest you can get to getting your hands on a Pandora right now is the Beagle Board. It uses the same SoC, the TI OMAP3530, although it uses the previous version with only 128MB of RAM.

I bring this up because one of the porting obstacles that hasn't been mentioned yet is the one I'm really running into a problem with on the Beagle -- RAM footprint. It's not so much of a big deal on x86 systems where you can just add more RAM, but on a system that only has 128 meg, of which Angstrom and Enlightenment use up 121 meg, you've got a really narrow window in which to operate. If your program uses more RAM than is available, you'll have quite a bit of work to do in order to port it. On the BeagleBoard, you can disable the X environment and free up another 80MB+, but that won't do for the Pandora (not for most users, anyway).

Luckily, a lot of this headache is mitigated in the Pandora with the new 256-MB chips (I'm really starting to appreciate how huge that upgrade is), but it's conceivable that some of the more modern emulators (like those for PSx or N64) or more resource-intensive games (like Doom 3) and other programs will need quite a bit of work to make them a little more frugal with how they use memory.

 

[senquack]

Usually on these specialized devices the input code must be modified and sometimes this is not trivial. The Pandora's analog volume wheel (assuming it still has this feature) reduces this effort somewhat.

Another area of difficulty that sometimes pops up is when the program does low-level pointer tricks. This can cause the program to segfault because the ARM doesn't support unaligned memory access. I am assuming the Cortex still behaves the same as the older chips.