The need for a standardised cross-compiler


Green7

Member
Joined
Mar 22, 2012
Messages
234
There have been a lot of great games ported to the Pandora from x86. Done, mostly, by very knowledgeable people who know Linux or, in special cases Linux and Windows, inside out. Originality, while not frowned upon, is not encouraged in my mind. It seems easier to take someone else's work and make it run on our, related, platform.


There is a dearth of Pandora specific games that take advantage of the form and controls. That's not to say there are none, there are some stand-outs and some dogs - as with any platform.


The single biggest obstacle to any hobbyist programmer like myself is a standard development environment.


I don't care if I have to use Windows, like Dev-C and the GP2X SDK or Linux and something like Code::Blocks.


Just something we can install that will be known to work.


Or is it just me?
 
Last edited by a moderator:
Yea, you're probably right - libmfrn.so.1.0 or whatever the feck it was called, was the bane of my cross-compiling life. Symlinking made no difference to my IDE. It just didn't work and I don't have the knowledge to fix it and gave up.


People who like heroin have a similar attitude. You know something us mere mortals don't :)


Do you think a fully set-up IDE is a bad idea?
 
the toolchains for the pandora are very simple, i use Ivanovic's script. It downloads and installed everything to one location. Then simply point yout makefile or your ide to the toolchain location i.e. bin, include, lib. I use codeblocks, it very simple to point it to a gcc cross compiler.
 
The only issue for me with toolchains (why I shy away from them) is that it's easier (I gather) to do it on a 32-bit GNU/Linux installation, but I've got a 64-bit one here. Or maybe it was that you needed to do something weird to your filesystem, like only have the 32-bit libs or something silly like that. Anyway, if it really is all that difficult, when I actually need it, I'll just end up installing some 32-bit GNU/Linux alongside the 64-bit one, so it's no big deal. :p
 
The only issue for me with toolchains (why I shy away from them) is that it's easier (I gather) to do it on a 32-bit GNU/Linux installation, but I've got a 64-bit one here. Or maybe it was that you needed to do something weird to your filesystem, like only have the 32-bit libs or something silly like that. Anyway, if it really is all that difficult, when I actually need it, I'll just end up installing some 32-bit GNU/Linux alongside the 64-bit one, so it's no big deal. :p
Just install multilib support (a 64 kernel run 32 binary just fine). (and redhat based system have linux32 command line to help you ;) )
 
I run Yactfeau on 64-bit Redhat Fedora 14 without issues. hmm I never need to use the linux32 command..


well I consider myself a novice on porting to ARM and I find the tools to be easy to use. however I am a programmer and been using Unix based OSs for a long time.. so maybe I have one up on many people.
 
Last edited by a moderator:
It did take me a little while to weigh up all the possibilities and find yactfeau, which seems pretty comprehensive. I do wonder about how autotools based projects work with it though. But autotools is something of a mystery to me in general
 
Last edited by a moderator:
My only issue with yactfeau, is that the PXML that is auto generated could be made a little bit more repo friendly and require a bit of editing to make it up-loadable to the repo... unless I missed an update that improved that.
 
Trashy: There is an updated genpxml script available at http://sebt3.openpandora.org/buildtools . This enables the package and licensetags etc.


Edglex: For autotools configuration, there is the pndconfigure script, that handles all variable setting for you and should function out of the box :) Also there is pndqmake and pndcmake in Yactfeau.
 
Trashy: There is an updated genpxml script available at http://sebt3.openpan....org/buildtools . This enables the package and licensetags etc

Great thanks for the Info!
 
Back
Top