minimalistic C dev environment on NAND

[notaz]

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.

 

[rygD]

is it possible to tell opkg to install stuff to SD?

 

[_jr_]

You can set the install root, I think it is just -o . The cdevtools pnd uses this.

 

[notaz]

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).

 

[levi]

Awesome!  I tried earlier today to install git, so I can do a bit of python hacking on the go, but forgot to update my feeds first.  Upgrading now.

 

[Wally]

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.
 

 

[pmprog]

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)

 

[_jr_]

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

 

[notaz]

Yeah if you mix objects or .a archives produced by different compilers, you'll get those messages. From what I've encountered they were mostly harmless.

 

[_jr_]

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)

 

[dimag0g]

 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.

 

[dimag0g]

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...

 

[_jr_]

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?

 

[notaz]

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..

 

[_jr_]

Thanks! Dependencies looking fine now.

 

[_jr_]

I know I sound like a broken record, but as a stripped down version of my above suggestion of updating Tcl/Tk it would be nice to cherrypick https://github.com/tcltk/tk/commit/8c3a30403be5d9565060d43975c91a7eff94664dto fix the tk 8.4.19 incompatibility with our xorg version (see http://sourceforge.net/p/tktoolkit/bugs/2472 for a discussion of the problem).

 

[notaz]

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..

 

[_jr_]

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

 

[notaz]

Ok rebuilt it, but it was only possible to rebuild all python, so there will be large number of python* package updates now..

 

[_jr_]

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!