minimalistic C dev environment on NAND


notaz

Certified Guru
Joined
Aug 23, 2005
Messages
4,913
Location
Lithuania
Website
notaz.gp2x.de
Since yesterday it is now possible to install working gcc compiler on NAND from OS ipk packages. Yes there is already Code::Blocks on the repo for that purpose, but it's huge (> 1GB), requires mounting the pnd every time you want to compile, has way more stuff in it than some projects need, and what's worst (for me) is that it's compiled against newer libs, meaning you have to carry those libs in a .pnd you release.

With this for ~20MB (or so) you get gcc with main system headers and libs. There is close to 100MB free after reflash, so I think it's pretty reasonable (in case you run from SD, it's not an issue, obviously).

Install commands:


opkg update
opkg upgrade
opkg install gcc-symlinks cpp-symlinks libc6-dev make
opkg install g++-symlinks # only if you need C++
From here, depending on your needs, you can install additional -dev packages, like libz-dev and libsdl-1.2-dev.
The downside is that all this is pretty old stuff from ~2009-2010, so no C++11 for you.. Also, in case you're releasing .pnd, there is a chance something depends on dev packages and pnd won't work for other users.
 
You can set the install root, I think it is just -o . The cdevtools pnd uses this.
 
There is now git available on the feeds (pretty old, but they keep protocol compatible), and the latest valgrind.

Good thing about this old 4.3-based gcc is that it's quite fast, I was able to clone and compile pcsx_rearmed in 5-6minutes which is not too bad, considering how old Cortex-A8 is now (did it all on /tmp to avoid SD slowness though).
 
Shame it doesn't support  C++11 :(

There's some projects that require C++11 to work and I haven't really got much clue to what libs code::blocks requires to be able to run them.
 
 
There's some projects that require C++11 to work and I haven't really got much clue to what libs code::blocks requires to be able to run them.
IIRC, it's not the libs, but the version of the compiler (gcc)
 
Since the update to binutils ld is now producing loads of

/usr/bin/ld: BFD (GNU Binutils) 2.21.1 assertion fail /srv/www/vhosts/notaz.gp2x.de/oe/tmp/angstrom.5/work/armv7a-angstrom-linux-gnueabi/binutils-2.21.1a-r1.3/binutils-2.21.1/bfd/elf32-arm.c:10188/usr/bin/ld: BFD (GNU Binutils) 2.21.1 assertion fail /srv/www/vhosts/notaz.gp2x.de/oe/tmp/angstrom.5/work/armv7a-angstrom-linux-gnueabi/binutils-2.21.1a-r1.3/binutils-2.21.1/bfd/elf32-arm.c:10188And my experiment of compiling http:\\racket-lang.org fails because of errors in the dwarf unwind info.

Do I need to reflash?


edit: problem only exists in combination with the gcc from cdevtools and seems to happen when ld reads /lib/ld-linux.so.3; if I understand the code correctly the assertion is about a FP attribute mismatch, so most probably unrelated to the racket problem


edit2: it seems the crt*.o included with the cdevtool's gcc 4.3.3 are responsible, calling the 4.3.3 collect2 manually with these replaced by their 4.3.6 counterparts fixes the assertion failures; probably time to ditch the cdevtools and find some space on nand for the various dev packages
 
Last edited by a moderator:
Thanks for the new toolset. The racket created with it seems to work so far (only tried the included picross like game yet which I remembered because of the other thread).


edit: one more question:) I see that libffi puts its headers into /usr/include/arm-angstrom-linux-gnueabi which isn't in the default compiler search path. Wouldn't it make sense to have these found without an explicit -I parameter?


edit2: an update to tcl/tk 8.4.20 would be appreciated to have git gui work out of the box (though lobotomizing the init files as a workaround is not too difficult)
 
Last edited by a moderator:
 probably time to ditch the cdevtools and find some space on nand for the various dev packages
That's too bad you want to ditch it, I'm trying to update cdevtools and shape it up right now. Unfortunately, I don't have much free time nor good integration skills, so it takes longer than expected.

Actually, this topic is very close of my view of what cdevtools should be. Up-to date tools building, *-dev packages for firmware libraries, plus a handy way to install extra libraries if needed. This way you always know what extras you have installed (and thus must package in your release PND), and if you fuck up with opkg, it only affects appdata/cdevtools and not root installation. Also, when you close it and run your PND, it will complain about all the things you forgot, because your firmware is unchanged.
 
All right, here's the beta of my work. I'm not sure what it will become in the end, maybe I should drop all creepy stuff like cmake and create a PND so small it could fit on the firmware...
 
Last edited by a moderator:
Doing a reinstall after reflashing I noticed, that pango-dev recommends elfutils-dev which depends on elfutils which conflicts with binutils-symlinks. Nothing else depends on or recommends elfutils. Do these have any use nowadays? Might be a good idea to remove this recommends dependency from pango-dev.


BTW: is there a way to tell opkg to not treat recommends as dependencies?
 
Last edited by a moderator:
The dependency issue should hopefully be fixed now.

As for opkg, it doesn't seem to offer anything except --nodeps . opkg is not that good really..
 
Updated to 8.5.8, as that's what classic OE git tree has. opkg is acting strange though and isn't updating the lib, until I reinstalled git-tk. I see it installed libtcl8.5.so.0 and left libtcl8.4.so.0 alone, kinda messy.. Hopefully isn't going to break anything..
 
Thank you very much! Git working even better now. The automatic update was working fine here. I don't think there can be any breakage, because Tcl/Tk isn't used by anything in the default firmware. Only python-tkinter depends on it (that's why the 8.4 libs are still there). But that did never work (that's how I originally stumbled upon this bug while porting PySolFC). If you can find the time to rebuild python-tkinter against the new Tcl/Tk the 8.4 libs could be removed and python-tkinter would be working in theory, though in practice it doesn't without manually installing the tcl and tk packages which may be too large to include in the default firmware. Still, even without having the tcl and tk packages installed by default, I could then remove the custom built python from the PySolFC PND (and there may be some other similar PNDs; I think kickass has used this in one of his PNDs, too). Not a very large win, though :)
 
Ok rebuilt it, but it was only possible to rebuild all python, so there will be large number of python* package updates now..
 
Great! Will test it when I get home. The large update is unfortunate, but if it's any consolation, other packaging tools don't seem to cope any better with packaging units that are smaller than the build unit. Python tries to make the extension build system separate, but I think it needs quite a lot of work to make it reliable in a binary distribution context. At least I couldn't get it to work reliably without a full build when I was working on PySolFC:)


edit: can now run PySolFC with the firmware python. Have to find some time for packaging an update. Thanks again!
 
Last edited by a moderator:
Back
Top