Cross-Compiling Is Bollocks! Toolchains Are Bollocks! Use Yo

[fdelapena]

If you get this error when compiling:

/usr/include/bits/local_lim.h:39:26: error: linux/limits.h: No such file or directory

You need to do this as superuser or sudo:

opkg install linux-libc-headers-dev

If you can not install libsdl-mixer-dev try uninstalling libsdl-mixer with --force-depends, don't forget to do opkg update before to prevent more errors.

 

[Beholder]

I wondered how long it would be before somebody started digging in to this. Great news and good job Torpor!

"This is means something. This is important."

 

[torpor]

Oh, come one share with us!

just give minimenu a poke.

To get things right: the development stuff can fit on a SD? Is it slower on SD than on the NAND? All the compiling creates temporary files. Are those in memory or are they wearing down the NAND life time? How is typing on the pandora like? Especially curly braces and the like.

Only the tools are on NAND, I put all my sources and temp files and projects on SD .. I'm absolutely sure that I will not abuse my NAND until long after I have moved on to other platforms ..

Anyway, if I bust my NAND because I'm compiling too hard, I've got another Pandora as backup. I'll let you know!

 

[synkro]

To get things right: the development stuff can fit on a SD? Is it slower on SD than on the NAND? All the compiling creates temporary files. Are those in memory or are they wearing down the NAND life time? How is typing on the pandora like? Especially curly braces and the like.

SD will be a smidge slower than NAND, but probably not all that noticable depending on the card. I've compiled stuff on SD cards before, and it wasn't horrificly slow or nothing.

Object files and the like appear in the same place as the g++ command was invoked, so you are burning your NAND if you're compiling there, or your SD if you're source code is there.

I wouldn't want to code directly on the Pandora's keypad, but I will in a pinch. I have 2 USB keyboards, one full size, and one mini-on-the-go sized.

a SD is easier to replace than NAND. carrying another keybaord is kinda weird.

 

[mindlord]

a SD is easier to replace than NAND. carrying another keybaord is kinda weird.

The full size keyboard is for at the house... although most likely I'll be using my desktop and accessing the sources over SSH. The mini keyboard is only marginally bigger than an Pandora that's laid open. It fits nicely in my backpack and weighs next to nothing.

Of course my backpack has other weird things in it too, so the keyboard certainly won't be lonely.

 

[fdelapena]

Finally tested, works flawlessly. It's a bit slow compiling but works. Pretty cool to make small software everywhere .

Video with SDL compiled app: http://www.youtube.com/watch?v=gnigHzSpZCU

 

[Stuckie]

I've just wrapped this "toolchain" into a PND file which calls up a Terminal, if it's of any use to anyone.

Wasn't quite happy about downloading and sticking stuff on the NAND, so I did some *cough* creative solutions *cough* to get GCC et al running via PND.
It's just the same setup as what Torpor describes in the first post - gcc, g++, SDL dev libs, vim, GLES demos.. nothing extra.

There's two ways you can run it, it either does an AUFS mount to /usr and /lib ( see, "creative solutions" ! ) or it just sets some path variables and lets you deal with it.
The former has the benefit of things "just working" but due to mounting an AUFS on to /lib and /usr, it wont let you unmount it ( least I haven't figured out how ) so you'll have to reboot rather than rip the card out. The extra benefit is you can close the terminal window and have access to gcc from other packages.
The latter gives up as soon as you close the terminal window, so it's a bit cleaner in that respect. And allows you to remove the card as normal, once you're finished.

If it's useful, I'll upload it somewhere ( not quite sure where, actually.. the App Store or ED's File Archive? )

 

[sinoth]

Sounds great, Stuckie! I'd love to mess with it. I've been thinking of doing something similar with Code::Blocks... gonna try to get it compiled for ARM and shove it into a PND. I think the 'add to path' method is probably the best.

 

[Stuckie]

I've stuck it up on my site just now till it gets tested some more... I have nightmares of lots of people killing me due to selecting the AUFS option, and removing the card before rebooting! I'd imagine all sorts of badness to happen.

Anyway, some oddities I've noticed so far.
While the AUFS hack works fine, the path mangling version has some issues.
Although I do overload the usual include and library paths as well as providing DEV_INCLUDE and DEV_LIBRARY, just to try make things a bit easier, it doesn't seem to do dynamic linking at all.. seriously, even with a good 'ol "gcc -o hello hello.c", it won't actually compile as it's trying to search for /usr/lib/libc_nonshared.a which obviously doesn't exist there, it's in the PND's hierachy instead! Curiously, doing "gcc -o hello hello.c -static" will actually build and link!
Very strange.

Hopefully someone can figure that one out without modifying the file system ( which is the point of me wrapping this in a PND, after all! ) as although you could do a symbolic link, that's naughty

Anyway, it's up here: http://www.stuckiegamez.co.uk/apps/pandora/pnddev.pnd
It's 90mb as I didn't bother doing CRAMFS or anything clever, and it'll show up in the menu under Development - Simple Dev Environment.
You'll then be asked whether you want the AUFS hack enabled or not.. clicking OK will enable, Cancel will do the Path mangling instead.

If there's any issues let me know, and I'll create a new topic for it, rather than continuing to hijack Torpor's

[edit]
The above download has now been removed as I've a much better setup in this thread: http://www.gp32x.de/board/index.php?/topic/54508-simple-dev-pnd/
[/edit]

 

[torpor]

stucjie its fine with me to keep things in this thread .. after all you are still not cross compiling!!



and thats really the point of this thread ..

 

[skeezix]

On my phone and didn't catch up but I saw a note up abou inputs..

Check libpnd pnd_io_evdev lib, it makes using nubs and dpad about 2 lines of code, really really easy

jeffphone

 

[Drack]

Off topic: It's absolutely hilarious how the forum syntax highlighted your readme.

On topic: This is awesome. But is it practical? And do you think vim is the right editor for Pandora? Don't get me wrong, I *LOVE* using vim and it's more than doubled my productivity at work (Where I'm forced to use Visual Studio...) but it's completely designed with touch-typing on the home-row in mind. Does that really scale down to thumb-typing on the Pandora enough that you don't want to just make a docking station or VNC into the damn thing with a full size keyboard? I realize using VNC is a copout (though less of one than cross compiling!) but seriously .. any serious vimmer will be using keys like @ ^ $ : . % / * a fair bit, not to mention coding itself which uses a lot of ( ) { } ;

 

[Creature XL]

In preparation for future development, I spent some time this evening getting my Pandora set up to support my efforts.

No, you do *not* need a cross-compiler environment, or separate external toolchain, or a copy of the PandoraOS Angstrom environment, to build fast, 3D apps for the Pandora, in C/C++. All you need is the Pandora ITSELF!

That is what i am telling Skeezix for years!

!! The following is not meant in an angry or rude way. I understand that OPT is not SONY, Nintendo, ... !!
----------------------------------------------------------------------------------------------------------
It would have been cool if there were an official cross-development suite, ideally with an emulator, BEFORE the device existed.
In such a way that I could have build an application completely on my PC (with LiNUX for that matter) and could be sure it runs on the Pandora.
Now i have an almost completed app lying around, which will not run until I get my Pandora


I am totally fine with the fact that no one of the "early" SW developers has time to compile libs for me, however, now that there are Ps in the wild, I might ask if anybody can build "cluttermm with OpenGLES back-end" and all its dependencies? I tried it with cross-building but I was a pain and it didn't work properly.

 

[torpor]

. But is it practical? And do you think vim is the right editor for Pandora?

I don't think vim is the 'right' editor for anyone except myself. Emacs, on the other hand, is an absolutely terrible editor and nobody should ever .. oh. Sorry. Wait. Never mind!

Seriously though, with the Code::Blocks port, I don't think vim need be mentioned in this discussion again. I'm using vim+cscope+make as my IDE for Pandora hacking right now, but thats because I love these tools and use them everywhere else as well - for on-Pandora hacking, I can't imagine anything other than being able to ssh in and use these tools .. but other hackers probably puke at the idea.

Don't get me wrong, I *LOVE* using vim and it's more than doubled my productivity at work (Where I'm forced to use Visual Studio...) but it's completely designed with touch-typing on the home-row in mind. Does that really scale down to thumb-typing on the Pandora enough that you don't want to just make a docking station or VNC into the damn thing with a full size keyboard? I realize using VNC is a copout (though less of one than cross compiling!) but seriously .. any serious vimmer will be using keys like @ ^ $ : . % / * a fair bit, not to mention coding itself which uses a lot of ( ) { } ;

On-Pandora editing seems cumbersome and tedious to me, unless you plug in a USB keyboard and hang some sort of magnifying device over the screen .. ssh-based native development really works and produces great results, imho ..

It would have been cool if there were an official cross-development suite,

There are quite some megabytes of NAND space being assigned to such rubbish as tens of "custom" Pandora desktop images, which in my opinion would be better allocated to having an onboard compiler/development suite *from the factory*. If the compiler tools were factory installed so that every Pandora came with everything you need to get started with development, we'd have a lot more productive programming going on around the Pandora scene ..

But as it stands right now you have to really know what you're doing to get cross-compilers installed, or wait for the community-based SDK project to get started .. or, you know, you could avoid all that bollocks entirely and just use the Pandora itself for development. If I were running the Base OS decision-making process, I'd chuck out the "fire and ice" desktop wallpapers and replace them with the compiler tools so that every single Pandora had exactly what it needs to build software for every other Pandora .. but thats just me. I don't see the advantage of having pretty things taking up all that valuable NAND when the developer tools are *far* more important to the community than some gimp output ..

 

[torpor]

Check libpnd pnd_io_evdev lib, it makes using nubs and dpad about 2 lines of code, really really easy

Got some copy-pasta you can show us? To be honest I'm finding the input side of things to be quite a drag .. spent a few hours last night trying to get an SDL app, which was very easy to port, to understand how to receive the " character properly .. this wonky keyboard mapping scheme seems needlessly incompatible. How does an SDL app get the fn-based characters normally?

Shouldn't those chars just be "normal" key codes?

 

[Creature XL]

[..]you could avoid all that bollocks entirely and just use the Pandora itself for development[..]

Well, you lucky f...
You have your Pandora(s). I am waiting on mine.
i was pretty unclear in my last post. What I have needed would have been an emulator with a toolchain. I knwo there are at least 2 community based projects, however, what is the worth of those? they will be done when all pandoras are deliverd. I guess each major company (who has the money and man power) builds emulators even before the real hard ware exits. How else, could there be any "launch titles" which aren't quick ports?

Then problem with releasing an app three or five month after the release of the P is that no one will use the app. I for one have never waded thru the thousands of apps in the GP2x archive. I only search those I need and know they exist.

Let alone, now my studies are finished I don#t have that much time to complete it.

@mcobit: you have your unit already?

 

[torpor]

How else, could there be any "launch titles" which aren't quick ports?

Hardware is rarely designed from scratch .. a lot of launch titles are developed on eval boards and Rev. A style hardware that still has bugs, or no cases, and so on ..

 

[skeezix]

Creature -- you're not telling me anything I don't know; feel free!

I don't have time to do everything for everyone, so you and everyone else can step in Of course you can build on your pandora, of course its awesome, of course I've done it myself, and of course thouuht of ways of making a pnd out of gcc+emacs+codeblocks+etc, but of course I get 50 requests a day to extend this or that, and I'm a tired out wreck from doing everything for everyone

So in no way did I ever suggest you should do otherwise; its just it can't always be the 3 or 4 of us who do everything, as I always said Witness - jayfoxrox started a vm approach, at east 3 or 4 people have made gcc pnds in the last week, etc; this is what our scene is about -- _everyone_ should be hacking, modding, replacing bits, extending; thats the whole pandora philosophy. Don't wait on me to try and do it... _GET TO IT_

jeff

 

[skeezix]

torpor -- for full end to end examples, no, course not I'm afraid

But for pnd_io_evdev it is super trivial to use. Reallys its..

open devices (whichever you want )

in main loop:
catch-up-io ( non-blocking )
if device-is-set: go left

close devices

Theres 4 functions to use -- open, close, catch up events, and chekc status:

http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-libraries.git;a=blob;f=include/pnd_io_evdev.h;h=450733ccef75eeb40a21d144b7204dc8a58803ae;hb=0f9a6f09fa46a15f661265c4b643cb7270d59d4c

We roll a libpnd ipk for installing into the firmware, of course, but we don't have a -dev version that includes the header files; we should make that, and put it in our repo (implication; we shoudl get our damned repo up , and good to go.

BTW, I'm going to be heavily tied up the nect 6 weeks probably (sigh), but I'll try to keep on top of gp32x forum.

jeff

 

[torpor]

We roll a libpnd ipk for installing into the firmware, of course, but we don't have a -dev version that includes the header files; we should make that, and put it in our repo (implication; we shoudl get our damned repo up , and good to go.

*PLEASE* do this! And also can you include the custom SDL and its -dev package too ..