Porting Guide


tsh

Active Member
Joined
Dec 19, 2008
Messages
777
Location
Cambridge
Website
Visit site
It seems everyone making PNDs already knows how to sort out an app so it can find things like shared libraries. There is a reasonable amount of discussion about how the PND should store data and such, but any obvious pointers for build configs? Maybe GMPC is a too ambitious start - but I thought since I have it compiled, I could share...
 
What you mean about build configs? Do you mean the ".conf" files that normally go into /etc or ~/.appname?

If you are talking about finding libraries from the PND, I use this script for my Game & Watch PND:

Code:
#!/bin/sh

export HOME=$(pwd)
export LD_LIBRARY_PATH=$HOME/lib:${LD_LIBRARY_PATH:-"/usr/lib"}
exec $HOME/bin/gameandwatch -d ./data
 
I'm interested also..i've set up Codeblocks and toolchain under Ubuntu but i don't have fully understand how to change the path to correctly
run under Pandora...mainly to avoid writing on NAND if possible .

If possible show it by real examples..thanks a lot.
 
Two ways..

Build with install path set to /mnt/utmp/appdataname

Or just build it and set LD_library_path to ./mylibs and lut needed libs into ./mypath in the pnd

This isnt a pnd thing, standard unix stuff

Jeffphone
 
I'd found the LD_LIBRARY_PATH in some other PNDs, but for the one i chose first, it ends up looking in /usr/share/ for all sorts of stuff. It does seem happy if I do
Code:
./configure --prefix=/mnt/utmp/appdataname
In my example, I also needed to do
Code:
export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
in order to find some libraries which I'd built from source.

It may be standard unix stuff, but most of us I guess haven't usually used any options when compiling from source, or if we have, it's been cut-n-paste from something like the ffmpeg-howto for ubuntu (followed by hours of cursing and confusion)

I'm slightly aware of the risk of too many people trying to generate PNDs without knowing much about what they're doing - but without the power of a main-stream distro we seem to either have to put up with old buggy builds, or DIY.
 
I was just clarifying that its not pnd in hopes folks may recall to look around for more nfo.. Not just here for pnd specific stuff

But yeah, it is an unusual beast :)

Sorry for brevity.. Phone typing ftl :)

Jeffphone
 
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.
 
SteveM said:
But everything up to this point is IMHO not porting but "merely" compiling and configuring.

Just to follow up on this, if anyone does cross the line into porting for real, remember you need to publish the source code once you change it.
Any tips on how to change are good too (like i get the impression that for gmpc, if I edit the source, I need to re-configure - just running make does not work). Again, standard unix, but then again, i don't remember running into (or needing) a guide on how to edit existing projects.

on PNDs, I failed to pass arguments to my runscripts (and I do remember seeing something about './script.sh --option' not found in the past). i wanted a 'do the firstrun setup again' option.

Jeffphone - phone keyboards suck for typing, particularly with android auto-correct!
 
Last edited by a moderator:
tsh said:
Any tips on how to change are good too (like i get the impression that for gmpc, if I edit the source, I need to re-configure - just running make does not work). Again, standard unix, but then again, i don't remember running into (or needing) a guide on how to edit existing projects.
That sounds a bit strange - just doing "make" should be enough, but with all the smoke and mirrors in autoconf it can become an incomprehensible mess. Sometimes you may just need to do a make in a different directory. And sometimes dependencies are just screwed up which may require you to persuade things along (e.g. by touching a file).

on PNDs, I failed to pass arguments to my runscripts (and I do remember seeing something about './script.sh --option' not found in the past). i wanted a 'do the firstrun setup again' option.
I've been thinking about putting together a "PND cookbook" on the wiki with recipes for scripts. Stuff like picking files, remembering directories, changing (and restoring) common system settings, offering configuration options, etc. All pretty simple when you get down to brass tacks but it might make a nice resource to copy-and-paste from.
 
Last edited by a moderator:
Back
Top