Pandora toolchain for Linux 2019

[slaanesh]

I didn't think it would be so difficult, but is there a modern Pandora toolchain available to run on a Linux PC so that I can do some dev?

I found the Mac OS X toolchain but I want to move away from this.
https://pyra-handheld.com/boards/threads/toolchain-for-mac-os-x.78069/

I know of the "on board" compiler by notaz - which is nice but it's slowish and a relatively old version of gcc.

I compiled my own on Linux but it's dated "arm-2013.11".

But is there something more modern? Something prebuilt and ready to go?

 

[TrashyMG]

Not sure anything like that currently exists. I think the only modernish toolchain is Ptitseb's Code::Block PND that has all the command line tools as well. But that runs entirely on the Pandora and not a cross-compiler.

 

[ingoreis]

I like the Idea to compile Pandora Software on a High End PC

But when you release Anything...please make a Howto for Noobs like me

 

[M-HT]

Few months ago, I used crosstool-NG to build a gcc 8.2.0 crosscompiler, but I didn't document the process. I also didn't test it much to see if everything works as it should.
Few years ago I documented, how I built a gcc 4.7.3 crosscompiler (with D language included) here.

 

[ptitSeb]

You can try to use this script: http://ptitseb.openpandora.org/crosscompilemaker.sh that should be able to build a workin gcc 4.9 and all dependancies (targetted to Pandora). From there you can build newer gcc, up to 9.1...

 

[slaanesh]

Okay I'm trying @ptitSeb script... It's running now.

So when you say "From there you can build newer gcc..." what does that mean?

 

[levi]

It means you can bootstrap a newer version of gcc using the older version in order to compile it. From my understanding though, you'd better limit the jumps you make, e.g. compile the latest 5.x using the 4.9 release, then 6.x using that 5.x build, and so on. I think that cadence is usually considered safe, and anything greater risks them using some feature that's not implemented in the version you're using to compile.

 

[slaanesh]

So I built the toolchain and it seems to be working but I get the following issue at the linking stage:

arm-linux-gnueabi-gcc: error: ELF####: No such file or directory

Those #### represent some weird characters that don't copy/paste.

I'm using libraries and header files that I copied from my Pandora and plopped them into my $HOME directory ie. $HOME/pandora/usr/include, $HOME/pandora/usr/libs, etc.

-Wl,-rpath,/usr/lib -Wl,-rpath-link,$HOME/pandora/usr/lib -L$HOME/pandora/usr/lib -lSDL -lpthread

 

[ptitSeb]

Did you build SDL 1.2 for the Pandora already? Or did you took the libSDL.so from some place (like codeblocks.pnd)?

 

[slaanesh]

I took all files .h .so. a from the Pandora...

My linux PC is 64-bit - Pandora is 32-bit...
[doublepost=1564034370,1564034153][/doublepost]@ptitSeb This method of taking files from the Pandora worked fine under Mac Os X and it is capable of building/linking very nicely.

 

[ptitSeb]

Yes, I use also the codeblocks.pnd as a source of libs on my cross tool chain (on linux 64bits) and it works fine, but I try to keep synchronised with the version of gcc inside codeblocks and the one in my cross-toolchain (so 9.1 in latest beta of codeblocks.pnd)

I have never encounter the error you list: ELF####: not such file or directory. I'm not even sure what it is trying to do to get this error in fact. Maybe, try to use gold instead of ld ? (use "-fuse-ld=gold -fuse-linker-plugin").

 

[slaanesh]

I don't get it either and also have never seen it during a compile.

Could it be a permissions issue?

I will also try a very simple program to see if I am able to compile that.

Is there anyway to get more information about what is happening? I'm already using -Wl,--verbose

 

[M-HT]

Is the cross-compiler executable 32-bit or 64-bit ? If it's 32-bit, it will not run if you don't have support for 32-bit executables installed.

 

[slaanesh]

The cross-compiler is 64-bit.

$ file `which c`
/bin/armv7l-unknown-linux-gnueabi-gcc: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/l, for GNU/Linux 3.2.0, BuildID[sha1]=38cdbcd64ee1fe329252ee255e0f8a64ed05e28f, with debug_info, not stripped

It compiles .c code fine, it gets the error on linking.

How can I tell which linker it's using? Maybe it's using the wrong one? Is that even possible?

The cross-compiler has been built into /bin which I thought was unusual - is that a problem? Usually they go into their own directories. like /opt/toolchain/bin... etc

 

[levi]

How can I tell which linker it's using? Maybe it's using the wrong one? Is that even possible?

I assume without further configuration it'll default to using /usr/bin/ld. Ptitseb already gave you compiler options to use gold instead, which I read now is an alternative linker for ELF files originally developed at google but donated to the GNU project last year. Archlinux doesn't seem to have a package for gold fwiw, and it's not part of the default build environment, so you'll have to download it and build it. Maybe other linuxes have it, but I'd be surprised.

 

[ptitSeb]

gold is present in gnu package for some year. I use it on Pandora for a long time already, and it's present on my Mint Linux... It's also built as part of the cross compilation toolchain IIRC, so the CFLAGS option will just work. And I doubt the regular ld will know how to link arm/softfp binary...

Also, don't forget Pandora is softfp, and ot hardhf architecture. So best flags are "-mcpu=cortex-a8 -mfpu=neon -mfloat-abi=softfp" (also, using "-fsigned-char" is most of the time a must-have).

 

[levi]

Ah, okay, there's no package in Arch, but ld.gold is part of the binutils package, so when I said it's not part of the default build environment I was mistaken.

 

[slaanesh]

gold is present in gnu package for some year. I use it on Pandora for a long time already, and it's present on my Mint Linux... It's also built as part of the cross compilation toolchain IIRC, so the CFLAGS option will just work. And I doubt the regular ld will know how to link arm/softfp binary...

Also, don't forget Pandora is softfp, and ot hardhf architecture. So best flags are "-mcpu=cortex-a8 -mfpu=neon -mfloat-abi=softfp" (also, using "-fsigned-char" is most of the time a must-have).

I already use the flags you mention above - I will add -fuse-ld=gold -fuse-linker-plugin and report back.
[doublepost=1564118759,1564099731][/doublepost]For best code generation and optimization, should -flto be used in conjunction with -fuse-linker-plugin?

 

[ptitSeb]

For best code generation and optimization, should -flto be used in conjunction with -fuse-linker-plugin?

Yes, but LTO has also some drawback. Start without LTO first. When you have something working, try with LTO.

 

[slaanesh]

So I've got this toolchain working okay with another (equally complex) project. It required a little tinkering around and setting a combination of -rpath-link (for the pandora's /lib and /usr/lib) and -L (for pandora's /usr/lib).

I didn't need to change to the GOLD linker.

I could perhaps try it as well to see if there are any differences.

Now I just have to get my original project working.