Release C/C++ Development Tools


Heya freamon .. any chance you've got a build coming out one of these days with all these bad boys in? :) I need to rebuild my chroot soon (been using the same one for about 18 months or so it looks like.. time flies!) .. but I'm thinking you've nearly got it all here already, might just save me doing it at all ;) (lazy, I know!)


- setuptools


- cython


- python-pygame


- python-opengl


- python-gst0.10 (gstreamer for video playback in python, win :)


- python-enchant


- gstreamer0.10-plugins-good


- python-dev


jeff
 
skeezix said:
Heya freamon .. any chance you've got a build coming out one of these days with all these bad boys in? :) I need to rebuild my chroot soon (been using the same one for about 18 months or so it looks like.. time flies!) .. but I'm thinking you've nearly got it all here already, might just save me doing it at all ;) (lazy, I know!)


- setuptools


- cython


- python-pygame


- python-opengl


- python-gst0.10 (gstreamer for video playback in python, win :)


- python-enchant


- gstreamer0.10-plugins-good


- python-dev


jeff
Click to expand...

The current version at the repo has:


setuptools


cython


python-gst0.10


python-dev


It symlinks to 'python-pygame' on the root os (is that the full version version on there?)


I couldn't find 'python-opengl'. I came across something 'Chris C' did ages ago, but didn't know if that would be enough.


I didn't include 'python-enchant' because it seemed a bit specialist to be honest. With all the python stuff already in there, it should be able to build python-enchant for you.


I didn't include 'gstreamer0.10-plugins-good' because they're already part of the CodecPack.pnd and I didn't think they were needed to develop stuff (my PNDs of Pogo and RadioTray both have the gstreamer plugins in them - they need them in order to run properly, but I didn't need them around when building).


Hope that makes sense - I'm happy to stick a new version up with those extra things in if my reasoning is wrong (which is entirely likely :) ).
 
freamon said:
I didn't include 'gstreamer0.10-plugins-good' because they're already part of the CodecPack.pnd and I didn't think they were needed to develop stuff (my PNDs of Pogo and RadioTray both have the gstreamer plugins in them - they need them in order to run properly, but I didn't need them around when building).


Hope that makes sense - I'm happy to stick a new version up with those extra things in if my reasoning is wrong (which is entirely likely :) ).
Click to expand...

I don't know how common it is, but I leave CodecPack.pnd uninstalled and rely on all my PNDs (eg. SMPlayer, PanPlayer, PyDance) to bundle them because CodecPack.pnd is so ancient that it doesn't support WebM at all.


Count this as a vote for assuming CodecPack.pnd is not installed.
 
Oh I think your reasoning is probably more clear than mine ;)


(I forget, do we have Emacs in there? If not, something to consider, though its a fairly sizable addition and likely specific to those ssh'ing or remoting in, since being so keyboardy based, its pretty tedious on the pandora native keyboard)


I was thinking the gstreamer bit was python wrappers or header-files or the like, but if its straight out gstreamer plugins, so I agree, should not be present. (The CodecPack is the right place for them, even if its out of date; if its out of date (and it is :) , _it_ should be upgraded, not something only partly related.) So, yeah, skip it, I'll make do and others ... if no one else asked, lets consider it moot, and revisit in the future if needed :)


edit: does cdevtools depend on codecpack? (when I got my new 1ghz unit, I fired up cdevtools, it blew up, I installed codecpack, and ran cdevtools again to success; but possibly I cleaned up appdata as well, which could have done it...)


python-opengl is a binding for wrapping up opengl and gles in pything (like a python 'ctypes' interface), though I think it is still fairly incomplete for GLES. Still, some things depend on it, and it does sort of work :) Feel free to ignore for now as well.


I really should build an 'automounting' addon for libpnd, so that folks could automount cdevtools at every startup ;) ie: if pndnotifyd finishes its work and sits, then wait until gui looks up or user is logged in or something, and then start mounting the list of auto-mounted pnds, could be amusing and a good way to crash your device ;) /media/*/pandora/auto ftw ;)


jeff


Ah, I see you did update the repo; thank you very much, you're awesome :)
 
Last edited by a moderator:
ssokolow said:
I don't know how common it is, but I leave CodecPack.pnd uninstalled and rely on all my PNDs (eg. SMPlayer, PanPlayer, PyDance) to bundle them because CodecPack.pnd is so ancient that it doesn't support WebM at all.


Count this as a vote for assuming CodecPack.pnd is not installed.
Click to expand...

Just to be pedantic: SMPlayer and PanPlayer don't use gstreamer - in the Linux AudioVisual Wars, they fight for the libav side. Python stuff does though - and I included gstreamer plugins in my PNDs of Pogo and RadioTray because I didn't assume every user had installed the CodecPack. I mentioned it more as: "If you're developing something that will require gstreamer-plugins-good, you can get it by cracking open the codec pack (or from angstrom, of course), and bundle it in you PND". I've no plans to put them in the cdevtools.pnd though, because - as mentioned above - they're not required during the building phase.

skeezix said:
I was thinking the gstreamer bit was python wrappers or header-files or the like
Click to expand...
I think they're in gstreamer-dev and python-gst, which are included.

skeezix said:
edit: does cdevtools depend on codecpack? (when I got my new 1ghz unit, I fired up cdevtools, it blew up, I installed codecpack, and ran cdevtools again to success; but possibly I cleaned up appdata as well, which could have done it...)
Click to expand...
Nope, doesn't depend on nothing. Works on a freshly untarred-onto-a-sdcard SuperZaxxon.

skeezix said:
(I forget, do we have Emacs in there? If not, something to consider, though its a fairly sizable addition and likely specific to those ssh'ing or remoting in, since being so keyboardy based, its pretty tedious on the pandora native keyboard)
Click to expand...
Emacs isn't included no. Based on Cloudef's pnd of it, it would add an extra 20mb (1/4 a size of the whole thing!). Besides, developing on your pandora by ssh'ing in is cheating, and shouldn't be encouraged ;)
 
Last edited by a moderator:
Okay I'm confronted with a new problem. Tried upgrading the libc6 package from the Angstrom repository. I got a segmentation fault and now I can't run the PND from the EXT2 (OS) partition anymore. It starts fine from the FAT32 partition. Moving it to, say, /usr/pandora/apps or my home folder, it's not responding. Moving it back again to the FAT32 partition it starts.


€dit: Okay got it solved by removing /pandora/appdata/cddevtools1000 on the EXT2 partition. Now to see if I can reproduce the segmentation fault.


€dit 2: Here's the segmentation fault



Code: 
Upgrading libc6 on root from 2.9-r35.3.5 to 2.12-r28...

Configuring libc6.

/mnt/utmp/cdevtools1000/usr/bin/addipk: line 24:  3004 Segmentation fault	  find $CDEVROOT -cnewer /tmp/cdev_time -name "*.la" 2> /dev/null > /tmp/cdev_la

/mnt/utmp/cdevtools1000/usr/bin/addipk: line 31:  3005 Segmentation fault	  find $CDEVROOT -cnewer /tmp/cdev_time -name "*.pc" 2> /dev/null > /tmp/cdev_pc

/mnt/utmp/cdevtools1000/usr/bin/addipk: line 39:  3006 Segmentation fault	  find $CDEVROOT/usr/bin/ -cnewer /tmp/cdev_time 2> /dev/null > /tmp/cdev_bin

/mnt/utmp/cdevtools1000/usr/bin/addipk: line 59:  3007 Segmentation fault	  find $CDEVROOT -cnewer /tmp/cdev_time -name "*.so" 2> /dev/null > /tmp/cdev_so

/mnt/utmp/cdevtools1000/usr/bin/addipk: line 120:  3008 Segmentation fault	  rm /tmp/cdev_*
 
Last edited by a moderator:
Git would be very nice to have, but there's a problem: git pull doesn't work. Try it and Git claims that "pull" isn't a valid Git command and directs you to --help (which lists "pull" as a command). This kind of makes Git completely useless.
 
Cyberworm said:
Okay I'm confronted with a new problem. Tried upgrading the libc6 package from the Angstrom repository.
Click to expand...

Eeeeek!!! If you upgrade libc6, you need to upgrade every program that uses it (i.e. all of them). Upgrading libc6 is a massive deal, and I think it only usually happens when a new version of a Linux distribution happens. 'rm' and 'find' in 'addipk' are segfaulting because they were compiled against 2.9, but are being asked to run using 2.12. You'll need to nuke the appdata directory to get it working again.

onpon4 said:
Git would be very nice to have, but there's a problem: git pull doesn't work. Try it and Git claims that "pull" isn't a valid Git command and directs you to --help (which lists "pull" as a command). This kind of makes Git completely useless.
Click to expand...

Oh. I've only ever tested it with 'git clone', which does work. But you're right about 'git pull'. I'll fix it in the next version, but for now, after you run the pnd, type:



Code: 
export GIT_EXEC_PATH=$CDEVROOT/usr/libexec/git-core

and then git pull will work.


If you're going to be using it a lot, you can update $CDEVROOT/.cdevrc yourself - underneath "export GIT_TEMPLATE_DIR=$pwd/usr/share/git-core/templates", add "export GIT_EXEC_PATH=$pwd/usr/libexec/git-core"
 
freamon said:
Oh. I've only ever tested it with 'git clone', which does work. But you're right about 'git pull'. I'll fix it in the next version, but for now, after you run the pnd, type:



Code: 
export GIT_EXEC_PATH=$CDEVROOT/usr/libexec/git-core

and then git pull will work.


If you're going to be using it a lot, you can update $CDEVROOT/.cdevrc yourself - underneath "export GIT_TEMPLATE_DIR=$pwd/usr/share/git-core/templates", add "export GIT_EXEC_PATH=$pwd/usr/libexec/git-core"
Click to expand...

Thanks! :)
 
Cyberworm said:
I see. It's a pity that the repository packages are so outdated.
Click to expand...

Not to mention worrying. If libc doesn't have a stable ABI, then how will we avoid mass PND breakage when things DO get upgraded?


(Though I do agree that it's a pity. If we had 2.12, then the ARM7 build of the closed-source Teensyduino GUI uploader that was made for the BeagleBoard would probably work on a Pandora. The binary format is compatible... it just refuses to run because libc is missing certain versioned symbols.)
 
What about not installing, but just LD_PRELOAD ing the newer version and everything it depends on?
 
Hmm... when you can just extract IPK files, then I guess that would be possible. I should give it a try.
 
Theres no problem with libc versioning really .. generally, for somethign like a Pandora console, where you do want to upgrade libraries to stay current.. you bundle multiple versions. If you look at any Desktop distribution, you'll find dozens of vesions of everything .. we don't want to go there, but we will ensure backwards compatibility by bundling some ABI-breaking libs for compatibility sake.


jeff
 
Could we get an updated version of Qt? It would make compiling gambatte and miniplayer much easier. (instead of having to go into pandebian every time)
 
As for the other libs, you will have to package newer qtversions into the pnd to make them run on every Pandora. So just take the newer qt from debian or from here:


http://sebt3.openpandora.org/buildtools/


and compile against that instead of the included.


I think there should be only libs in the cdevtools in the versions that are present on the Pandora system by default.
 
Last edited by a moderator:
mcobit said:
I think there should be only libs in the cdevtools in the versions that are present on the Pandora system by default.
Click to expand...

I agree.


There's going to be an increasing amount of stuff that will require QT 4.7 though. It might be an idea if I (or someone else) created a "QT 4.7 Development Tools" pnd (with just the QT stuff and a C++ compiler in it). Although, like mcobit said, any pnd that was ultimately created would have to contain the relevant QT libs in aswell, so they'd all be pretty big.
 
Not saying it will fix you glib issue, but with this:



Code: 
./configure --target-list="i386-softmmu x86_64-softmmu"

your targeting to build qemu for a regular x86/x86_64 processor.. not for the ARM processor which the Pandora has.


if your compiling on the Pandora you may just need to run ./configure which should automatically detect which architecture is being used.
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top