Just some random ramblings from me, not directed at anyone in particular:
I've found very few programs for which "./configure" options were enough to get things running right on the Pandora. If the package even has a configure script (a lot of emulators, games, etc. don't) it's not always set up to cater for every foreseeable combination of compiler, libraries, paths and what-have-you. So whilst "./configure && make && make install" will probably get you running on a PC, it doesn't always work as well when doing anything remotely "exotic" like cross-compiling. The bigger, better-known packages usually have this nailed, especially the mainstream software that runs on every Linux distribution you can think of. The more obscure you get, the more chance there is of needing to do some actual work ;-)
Number one tip is to run ./configure --help and scan through for obvious stuff like libraries to use, features to enable, paths, etc. You can chop out a lot of obviously superfluous stuff this way and therefore cut down on dependencies and the amount of work required. If you're lucky you'll get a working build out of it, possibly requiring a few command line arguments to set video options or reference a configuration file suitable for use on the Pandora (which you will most probably need to write/taylor yourself). How far you get of course depends on how configurable the program is, both at compile time and at runtime.
Sometimes even if the ./configure step won't play nicely you can wangle it in other ways. Poking around in the generated header(s) (config.h) and Makefiles is often a lot easier than wrestling with an uncooperative script. At the end of the day, everything that's not hard-coded into the sources has to come from one of these generated files. Thankfully it's usually pretty simple to change parameters if you know what it is you want to change (grep -r is your friend ;-) If the software supports it, this is often a good chance to replace absolute paths which ./configure will often stubbornly insist on with Pandora-friendly relative ones.
But everything up to this point is IMHO not porting but "merely" compiling and configuring. (I say "IMHO" to hopefully avoid arguments about semantics and quote "merely" as it can be quite a task in and of itself.) However, more often than not you will need to jump into the code to see what's going on. Sometimes you get away with minor changes (e.g. changing hard-coded paths, video options or whatever) and sometimes you need to rewrite lumps of code of varying size (rendering, scaling, audio, event handling, etc.) to get things going how you want them to. That last bit is what I'd call porting.
