Toolchain Problems...


prak

Still Fresh
Joined
May 12, 2008
Messages
7
Hi, I wanted to start playing with porting compiling, etc...
I have _installed_ arm-2008q1-126-arm-none-eabi-i686-pc-linux-gnu.tar.bz2 from CodeSoucery
CODE

$ tar -xjf arm-2008q1-126-arm-none-eabi-i686-pc-linux-gnu.tar.bz2
$ sudo mv arm-2008q1 /opt/
$ echo 'PATH=/opt/arm-2008q1/bin:$PATH' >> ~/.bashrc


And tried to compile:
CODE

$ cat test.cc
int main() {return 0;}
$ arm-none-eabi-g++ -T /opt/arm-2008q1/arm-none-eabi/lib/generic.ld test.cc -o test
cc1plus: warning: include location "/usr/include/libffi" is unsafe for cross-compilation


google:"is unsafe for cross-compilation" guides to discussion on libffi list, where one guy advices -Wno-poison-system-directories as solution, someone playing with scratchbox. (Sorry, don't have link atm)
This solves nothing, it seems, but no compiler warning (false positive?)
Compilation is successful, but using some emulator (qemu based?) from above toolchain just hangs:
CODE

arm-none-eabi-run ./test



I've no idea if this binary will run on real device...
Anyone knows, what I am doing wrong?
 
"is unsafe for cross-compilation" means you are using system include directory rather than cross compilation include directory. Eg. you are using your host system include files (Intel Linux) rather than files meant for arm compilation.

Host system include files are typically stored in "/usr/include", where the arm ones would be installed with the compiler (I'm guessing /opt/arm-2008q1/arm-none-eabi/include or similar).
 
You picked the wrong toolchain. The one you chose is for boards with no OS.
Try arm-2008q1-126-arm-none-linux-gnueabi-i686-pc-linux-gnu.

However that doesn't mean you will be able to run the executable with qemu ;)
 
Laurent said:
You picked the wrong toolchain. The one you chose is for boards with no OS.
Try arm-2008q1-126-arm-none-linux-gnueabi-i686-pc-linux-gnu.

However that doesn't mean you will be able to run the executable with qemu ;)
Thank you both, downloading correct now, guess i will have to assume that if it compiles with both toolchains, and works with native, it works... :) Not very good assumption, but I can't do better, can I?
 
Last edited by a moderator:
Your best bet is to use gcc on your x86 Linux using SDL and imgtec OpenGL ES 2 emulation layer. That should be enough while waiting for the real HW and its associated OS setup :)
 
Laurent said:
Your best bet is to use gcc on your x86 Linux using SDL and imgtec OpenGL ES 2 emulation layer. That should be enough while waiting for the real HW and its associated OS setup :)
I'll second that line of thinking. Most of what you need to learn to do to produce content for the Pandora will be able to be done in the x86 linux world. :D

You just need to show care about bad assumptions in your code- avoid treating pointers as ints (Not an issue for a Pandora, but it might come to be on the next gen of it...), presumptions
of byte orders being consistent from x86 to other platforms, etc. Do best practices and largely portable code and you'll do reasonably well.
 
Last edited by a moderator:
I've got some noob question concerning compiling for the Pandora (I'm not really good at writing my own make files etc.):
  • Is it save to assume that someone will provide a pre-configured DevC++ and/or CodeBlocks environment for us Windows users to cross-compile? (incl. the most important libraries, such as SDL, SDL_image, SDL_Mixer, etc., just as we have for the for the GP2X)
  • and slightly off-topic, but also related to development libraries: Is anybody planning to port the sqlite library to the pandora? Since its source code is in the public domain and a Linux port exists, I assume this is reasonably easy for a more experienced programmer than me. (I've only discovered it a couple of weeks ago and love it to bits.)
Thanks!
 
I don't know about the first question, but sqlite is basically just a compile away.
 
Back
Top