Yactfeau

[Exophase]

I installed the latest toolchain today because my toolchain from last year had a bug in its as that's not allowing it to accept any immediates I try in vbic/vorr in NEON.

After installing I'm finding that the bug is still there, but more alarming is that the versions of GCC and AS are actually older than I started with! They're both from 2008 distributions. I'm probably going to go back to my old toolchain but update the compiler part with the latest CodeSourcery or whatever (I know they can be buggy but I'll take my chances), but is there any reason why the components of this toolchain are so old? This is pretty critical for ARM development, it's not taking advantage years of backend improvements.

(please understand, I do appreciate what you're doing, just curious)

 

[ivanovic]

After installing I'm finding that the bug is still there, but more alarming is that the versions of GCC and AS are actually older than I started with! They're both from 2008 distributions. I'm probably going to go back to my old toolchain but update the compiler part with the latest CodeSourcery or whatever (I know they can be buggy but I'll take my chances), but is there any reason why the components of this toolchain are so old? This is pretty critical for ARM development, it's not taking advantage years of backend improvements.

The reason is simple: this one is directly based on the OpenEmbedded Recipes that also create the pandora image itself. So it uses the same compiler, the same glibc and all that stuff, as is used if you had it on the pandora.

If you want a toolchain with all the stuff that is available on the pandora but based on the latest codesourcery compiler, you should have a look at the toolchain setup script I created: http://www.gp32x.de/board/index.php?/topic/58443-crosscompiler-toolchain-based-on-openpandora-org-ipks/page__p__936553&#entry936553
The basic difference between these two toolchains is the compiler provided, the rest is rather similar.

 

[Exophase]

Thanks Ivanovic. I manually copied over the latest CodeSourcery over my old toolchain, but I'm sure I'll find out I messed up something later (right now just running some code without any of the Pandora libraries so..). So I'll probably move to your toolchain.

Looks like the OpenEmbedded folks should update.. I know using CS is a little risky but at least newer versions of GCC mainline have incorporated a lot of the improvements over the years.

(btw, that bug I found was really in my inability to read the manual )

 

[Schnatterplatsch]

I keep on getting the "/usr/local/angstrom/arm/libexec/gcc/arm-angstrom-linux-gnueabi/4.3.3/cc1plus: error while loading shared libraries: libmpfr.so.1: cannot open shared object file: No such file or directory" error.

After I failed fixing it several times(also tried PokeParadox suggestion... no luck), I have now reinstalled the toolchain and would be extremly grateful to get a step-by-step guidance.

I followed those steps to install the thing: http://pandorawiki.org/Setting_up_a_cross-compiler

Next I commented out the named lines in environment-setup.

And now? Which script am I supposed to run???

Thanks in advance

 

[bzar]

I've commented on this problem before somewhere in this thread. The problem is probably that you use a 64bit distribution which doesn't have a 32bit version of libmpfr available. The solution is to link to another file that seems to be binary compatible. The exact steps are mentioned in that older post of mine

 

[Schnatterplatsch]

I've commented on this problem before somewhere in this thread. The problem is probably that you use a 64bit distribution which doesn't have a 32bit version of libmpfr available. The solution is to link to another file that seems to be binary compatible. The exact steps are mentioned in that older post of mine

Mmh, I am pretty sure I have a 32bit Ubuntu.
I've got libmpfr.tar.gz here(PokeParadox linked it somewhere) so maybe you could just tell me where to place it?

 

[bzar]

IIRC in /usr/lib

 

[Schnatterplatsch]

IIRC in /usr/lib

Okay. I installed libmpfr via synaptic, but it just created libmpfr.so.4 not *.1. A symlink to libmpfr.so worked, I am no linuxprofi so I hope that was the right thing to do.

Anyway, thanks!

 

[sebt3]

Okay. I installed libmpfr via synaptic, but it just created libmpfr.so.4 not *.1. A symlink to libmpfr.so worked, I am no linuxprofi so I hope that was the right thing to do.

that's good

 

[Farox]

In the last few days my Yactfeau toolchain got corrupted (the EXT4 File system got corrupted ...to be more precise) i'ts still booting and seems to work but
now every files (text,image,datas) that i try to copy onto Ubuntu ir unreadable.

Are you still working on this ? ( an upgrade will be nice)

 

[sebt3]

Are you still working on this ? ( an upgrade will be nice)

I have a few changes ready, but nothing important enough to upload that rather large package.
I'll update this for .next in a few months I guess

 

[Farox]

ok thanks...ill wait until then

 

[sebt3]

ok thanks...ill wait until then

Hey redownload the current version (and the updated genpxml :http://sebt3.openpandora.org/buildtools/?f=genpxml) !
Dont dare stop porting stuff until I update this

 

[Farox]

I have already the original image...and all the update that you made after...so in some days i will return to build for Pandora....but to have an updated toolchain will be very nice.

 

[bukkit]

Hey redownload the current version (and the updated genpxml :http://sebt3.openpandora.org/buildtools/?f=genpxml) !
Dont dare stop porting stuff until I update this

I try

OK, this thread hasn't seen action for a while, I hope this is not considered zombieism... I used your Virtualbox toolchain image for quite a while; after a longer hiatus I tried to compile sth made for std=c++11. I tried std=c++0x, but that doesn't quite cut it; 4.3 seems to be just too old for that. I'm not really proficient with cross compiling toolchains, so could anyone tell me how difficult or easy would it be to get to a newer g++, preferably > 4.7, and keep the rest of that environment?

 

[Wally]

Just use the code::blocks PND

 

[bukkit]

Just use the code::blocks PND

I know that, have that- but never used it. I do appreciate the pnd, but with my development environment (one or two 24" screens), eyesight, finger size and dexterity, I consider it a last resort. Also, most of the time I find for developing for the Pandora, I don't have it present. So while I'm really glad about it's existence, being reduced to using it would reduce my development activities to, maybe, 5%... important 5%, but still...

But seeing your like, sebt, am I to interpret this as a "I dont't work on that anymore and it's not easy to just upgrade the compiler?" You know, I certainly understand that, but it would be good to know.

 

[ptitSeb]

I know that, have that- but never used it. I do appreciate the pnd, but with my development environment (one or two 24" screens), eyesight, finger size and dexterity, I consider it a last resort. Also, most of the time I find for developing for the Pandora, I don't have it present. So while I'm really glad about it's existence, being reduced to using it would reduce my development activities to, maybe, 5%... important 5%, but still...

But seeing your like, sebt, am I to interpret this as a "I dont't work on that anymore and it's not easy to just upgrade the compiler?" You know, I certainly understand that, but it would be good to know.

I use codeblocks PND my self, but remotly: I share my Pandora disk (using samba, so I can access them from my Windows, but sshfs is also doable) and open a putty screen to do my compile (there are detail, somewhere in the forum, on how to do taht, but I don't remember what thread).
Then I use VSCode or Notepad++ (or simply nano in the putty) to do the editing.
That way, I build on the Pandora (easier most of the time, even if slow) but still benefit for my large screen, full size keybord and mouse.

If you prefer, I do have a script (somewhere again, I don't remember what thread) to create a cross compile environnement from scratch. But you will only get a bare compiler with minimum set of lib. No SDL, no nothing (you'll have to build that yourself).

If you are interrested in detail from one or another solution, just ask here.

 

[sebt3]

But seeing your like, sebt, am I to interpret this as a "I dont't work on that anymore and it's not easy to just upgrade the compiler?" You know, I certainly understand that, but it would be good to know.

Well it's a bit complex.
IMHO yactfeau have served it's time now. It was meant to provide an easy way to build PND using the toolchain that is used to build the OS. But that toolchain is dated now. I do clearly get why you want a newer toolchain. But that wont be yactfeau.
There's ianovic's script to build a newer toolchain and you could slap my helpers on to of that (just adapt the environement-setup file).
Then I know ptitSeb also have his own cross-compiling environnement. He may want to document it / provide delivery stuff.

But yactfeau will never get a newer toolchain. I'm still willing to maintain it as it is if anyone needs it.

 

[bukkit]

I thought sth like that. Thanks for all your answers. @ptitSeb: Yeah, I thought about that. Besides compile time and memory/storage restrictions, it's also like I mentioned: I usually don't carry my Pandora to work everyday (I know, a crime in itself), so it isn't handy most of the time when I find time to code sth extracurricular. But that would be the goto option. Or I start to really get into the intrinsics of cross-compiling... the script you mention should help to cut some Pandora-specific corners...