Release C/C++ Development Tools


Hi,

first of all, this PND is quite awesome. I used it to compile sparrow3d and snowman an my pandora.

However I had to change some things first and even to repackage the whole pnd.

  • Your symlink libSDL_mixer.so is broken with the recent firmware. It should point to /usr/lib/libSDL_mixer-1.2.so.0
  • a symlink to libpnd.so.1 and the pnd_*.h headers are missing at all
  • maybe you could add a folder like /usr/local/lib_fixes or similar as first entry in the PATH-variable you set? In that case users could easily add/repair symlinks on their own or even add whole libraries. Same would maybe be useful for includes.
greetings,Ziz
 
Ziz said:
Hi,

first of all, this PND is quite awesome. I used it to compile sparrow3d and snowman an my pandora.

However I had to change some things first and even to repackage the whole pnd.

  • Your symlink libSDL_mixer.so is broken with the recent firmware. It should point to /usr/lib/libSDL_mixer-1.2.so.0
  • a symlink to libpnd.so.1 and the pnd_*.h headers are missing at all
  • maybe you could add a folder like /usr/local/lib_fixes or similar as first entry in the PATH-variable you set? In that case users could easily add/repair symlinks on their own or even add whole libraries. Same would maybe be useful for includes.
greetings,Ziz
Click to expand...
I reimlemented the changes today again, but without repacking the PND (was a stupid idea...), but with just adding the missing symlinks and header files directly in the mounted PND. It is quite awesome, that they are created in the appata folder in the background. The only thing, that I had to consider, is to use an ext2 filesystems for the appata of cdevtools. But as I have two partitions on my 64 gb sd card anyway, that wasn't a big problem at all. ;)

The pyra should really keep the PND system or change it only a bit (like the discussed tar ball around it)!
 
I use it often too for trying Things ;)

Can you update the LibGL from LinuxBochs inside too?

When it so easy work can we maybe port much more Games/Applications then ;)
 
Do it yourself! Just put the libraries or symlinks you want to /mnt/utmp/cdevtools1000/usr/lib ;) For symlinks you need of course a file systems, which supports it. ;)
 
Do it yourself attitude is great, but cdevtools really deserve an update. It's been a while.

And I really hope it will stay minimalistic and won't get bloated like codeblocks PND. I would even prefer to have python out of cdevtools and into a separate PND.

And I'd love if the maintainer could make cdevtools PND CLI-compatible, so I could start it without X11. All you have to do is start plain old bash if rxvt fails to start.
 
You can override the start script through appdata (I do that already to call my own setup script that sets various env variables).

But I agree an update would be nice, though - with some issues not really being fixable unless the tool chain is actually installed in the standard directories (too many differently broken build scripts out there) and Pyra having a standard distribution - the incentive to work on this is probably rather small.
 
Being tired of waiting, I have updated the pnd myself.
- Outdated packages have been updated (including SDL)
- A few missing packages were installed (so pnd_* files are in place now).

- addipk script now uses --nodeps option, so you will have to install packages one by one (which is better IMO)
- Python 2.6 was ripped off, and some of Python 2.7 packages were installed instead, but I don't use python and thus have no idea if it works.
- startup script now works without xorg server, although it's a dirty hack and there is no job control in the terminal
- appdata folder name was changed to cdevtools. If you want to reuse cdevtools1000 from the original PND (by renaming it to cdevtools), don't forget to remove the init subfolder so the paths get updated

cdevtools.pnd
 

Attachments

  • cdevtools.pnd
    59.2 MB · Views: 217
Last edited by a moderator:
Eventually, if the author adds me to maintainers. I'd like it to be tested by skilled people first, as I have little knowledge on toolchains and I'm afraid to produce a broken version (although I just managed to build my redneck rampage port with this PND, so it seems to work)
 
dimag0g said:
Eventually, if the author adds me to maintainers. I'd like it to be tested by skilled people first, as I have little knowledge on toolchains and I'm afraid to produce a broken version (although I just managed to build my redneck rampage port with this PND, so it seems to work)
Click to expand...
Got it. By the way is there any advantage in this toolchain vs the codeblocks pnd ? (apart from the size?)
 
I ran into some (different) problems with both toolchains. So my benefit is to have an alternative if something doesn't work.

@dimag0g: I will test your repackage these days!
 
One of the main advantage of cdevtools is that it use the same compiler as the one use to build the kernel. So you can compile things that have much less dependencies with newer library. With codeblocks, you have to embed with a pnd many libs wich supercede the one in the firmware.
 
ekianjo said:
Got it. By the way is there any advantage in this toolchain vs the codeblocks pnd ? (apart from the size?)
Click to expand...
Size is one thing. Another one is the update possibility. Should there be a newer libblabla, you can just remove the old one with opkg -o $CDEVTOOLS remove blabla-dev, then install the new version with addipk blabla-dev

Yet another important aspect is flexibility. I plan to make scripts for all my projects, which you can just run inside the cdevtools shell (while being online) to install the latest version of all necessary libraries for that project. The goal is to enable anyone who wants to participate to get started. Building from the sources should be as easy as typing git clone git://project.org; cd project; ./cdevtools-conf.sh; make inside the cdevtools shell.
 
Last edited by a moderator:
dimag0g said:
Yet another important aspect is flexibility. I plan to make scripts for all my projects, which you can just run inside the cdevtools shell (while being online) to install the latest version of all necessary libraries for that project.
Click to expand...
you mean it will install and compile all dependencies necessary at once ?  
 
I tested it, it works fine for me.

And I don't need my work arounds anymore, so thanks.
 
Ziz, maybe you could advise on the subject of 3D dev libraries? Do you think there are libraries that merit to be included in cdevtools by default? I'm thinking about linuxbosh's gl wrapper, but I understand it is still in heavy development, so including the current version in the PND will do more harm than good, as it will become outdated pretty soon.

There is AFAIK some sort of SDL modification compatible with GLES, maybe I should include this one? If so, could you point me to some stable release?

There is also glues library and eglport. Do we need those in cdevtools as well? eglport.c should be compiled with the project, so there is no place for it in the toolchain, right?
 
Last edited by a moderator:
First of all, all my 3D experience on the pandora is based on my software renderer. So in fact I may be the wrong contact person.

However, if you include a library, which is not part of Super Zaxxon 1.6X, the developer has to put it to the PND (or to link is staticly) anyway.

Furthermore it is quite easy to add libraries, which you may need on your own without repackaging the whole thing. So if somebody needs Lunchbox' library, (s)he can always add the most recent on on h(er/is) own.

Also: If we start to add libraries, because they MAY be useful, we will end in a 3GB PND like Code::Blocks in the end, too. ;)
 
You must log in or register to reply here.
Back
Top