tools
tools copied to clipboard
raspberrypi
GCC version not upgraded
What is the purpose of this repository? Is it supposed to provide a cross compiler that matches the gcc --version of the current raspbian image? Will there be updates of any of the toolchains in the repository?
There is a growing number of projects that will no longer compile with gcc 4.8 and 4.9 support will see a similar fate. I am aware that there is an awkward C++ ABI change with gcc 5.0, but that step has to be made at some point.
I have been testing a newer gcc but unfortunately it failed testing. I'm using crosstool-ng with this configuration I can build kernel and /opt/vc/lib libraries fine, but kodi seg-faults on launch.
If you want I built a cross toolchain gcc 6.3.0 for Stretch that seems to work for me for the moment. I built Qt, ffmpeg, omxplayer etc... I also tried kodi but I get an illegal instruction. It is built for armv7-a. I also built one identical for Mac OS. I uploaded the binaries here.
@carlonluca please provide the build steps for your toolchain. I would like to build them myself
@robiwano no, crosstool-ng was giving me problems with the paths. I didn't investigate further. @crapp there are many guides on the web, I think I followed something like this.
Developer support is incredible bad! gcc 4.8, gcc 4.9 - Guys, 2018!!!!! We need a modern compiler. Don't waste your time with crap like Rasperry PI Desktop. Building a cross-compiler, specially on Mac, is not something every developer should have to do on his/her own. Even ESP32 (Espressif) has a x-compiler for every major OS. Raspberry-Org makes good money with their devices - it should be possible to provide us with a cross-compiler for Mac, Windows + Linux.
Wow, how rude.
All internal development at RPT is done using either the Pi itself, or desktop Linux with the supplied cross compiler. We don't have any experience in house in Windows or Mac cross compiling.
So I would suggest either doing dev work on RPI itself (using the RPI desktop, which is not crap BTW), or installing a VM with Linux and use the supplied cross compiler. It is old, but it works.
I'm sure that at some point we will release a newer x-compiler for Linux, but it requires a lot of work and even more testing (see comment above), and we are busy right now.
But the thing is, it doesn't, does it? Raspbian Stretch (f.i.) is built with the GCC6.3.0 toolchain vs. GCC4.9.3 which is the one available. As the ABI changed somewhere around GCC5 (?) linking to OS provided shared objects might lead into a world of hurt, and hard to debug errors.
That said, I for one do appreciate all the work you are doing at RPT, and I was able to find a x-toolchain to use on Ubuntu and also the one provided with VisualGDB, which works fine on Windows.
Sorry, I was assuming people were wanting to cross compile kernel building, not 'app' building. I use the cross compiler for kernel builds all the time. However, for Pi app builds I use the Pi itself. Generally fast enough for the stuff I do - and the guy who does the dev work on the desktop uses the Pi for all of that as well, so clearly its fine for some fairly heavy lifting.
I think the solution here is to tell people to use the debian or ubuntu repositories for building applications and kernels i.e. use the cross compilation packages from stretch if your are a lucky linux user or have the resilience to run the linux subsystem for windows10. Or use a VM solution..
I only came across this repo because a user reported issues with running our binaries... which were built with a new compiler. He told me that here I would find the official ones..
@APokorny No - the solution is a cross-compiler for Windows and Mac! @JamesH65 I know that was rude - but as said: Raspberry Foundation made ~9M £ in 2015 (don't have the numbers for 2017), Expenses ~6.3M in 2015. This whole thing is a business and not just a fun project. Raspberry-Pi is 2 or 3 times more expensive than for example the Orange Pi. For this price I expect things like a cross-compiler and not someone telling me that it's fast enough to develop on the Pi or that I should use Linux/Docker/VM...
For $35 you expect a cross compiler for Windows and Mac, two systems we don't support?
The RPF profits are pushed back straight in to education. There are limits to how much of the profits the trading arm can take of course. But TBH, the amount of profit made by the RPF is irrelevant to the decision on whether to spend a load of money building and supporting cross compilers for platforms we know nothing about. What more important is does that effort pay itself back? And the answer is, currently, no it doesn't. Lets say 1000 people want to work on a Mac, assuming profits per Pi of $3 (made up number), that's $3000 to build and support a cross compiler, ad infinitum. A completely inadequate amount of money for the effort involved. Now add the Windows version, perhaps 10000 people want to use the Windows cross compiler. We now have $30k to play with - STILL not enough. For example, we were just quoted $35k just to write a device driver for a USB wireless dongle. To do the cross compiler work, and SUPPORT it would be way more.
So, yes, we are running Raspberry Pi as a business!
I'd suggest using the Orange Pi cross compiler.
Microsoft makes a a hell of a lot more money and yet Visual Studio for Mac doesn't cross compile C/C++ apps for Windows, does that mean 'Developer support is incredible bad!' there too ?
The solution is to use a VM.
@WayneKeenan - MS ignored Mac and Linux because they were competitors, now they are loosing business to Mac and Linux and they have to support those systems...
@JamesH65 How much did you pay for Pixel??? A very conservative looking DE where everyone had XFCE, LXDE + Mate as an option - However...
33K for building a cross-compiler for Mac + Windows - are you kidding? If you pay 50$ per h than you have 660h - ~19 month!!!! to build a these two compilers. ESP32 costs less than 5$ and they were able to provide their customers with an adequate compiler suite btw.
It seems that this thread has gotten way side tracked...
@MikeMitterer, please find another more appropriate forum to discuss your opinions. This thread is strictly for addressing technical issues regarding the cross toolchain.
I would suggest closing the issue since it appears that @APokorny has a workaround. However, it seems that there is still active effort in updating the cross toolchain.
What? There's no workaround or solution, other than using carlonlucas binaries at the moment, unless I missed something? I mean, Raspbian Stretch was built with the 6.3.0 toolchain. Wouldn't it be possible to just provide that toolchain for running on Ubuntu f.i. ? I'm fine with running on a VM, as long as I have something to run. Right now I use the toolchain provided by SysProgs.
I never stated that the issue currently has a solution. And as for workarounds, I (possibly incorrectly) assumed you had a workaround based on your posts...
I was able to find a x-toolchain to use on Ubuntu and also the one provided with VisualGDB, which works fine on Windows.
other than using carlonlucas binaries at the moment
Right now I use the toolchain provided by SysProgs.
If, in fact, none of the above are useful to you (or anyone else) as a workaround then I'm sure we can find something else that can be until an updated toolchain is available.
@MikeMitterer Have you tried cygwin on Windows? Also, I've seen plenty of people using gcc on MacOS, so I'm sure you should be able to cross compile there as well.
@johnmanko Thanks - but I was able to compile an older version of the cross-compiler for Raspberry on my Mac but it's a hassle. Mac uses clang (not gcc) and the filesystem is not case sensitive - these are the main problems. It's a very annoying, error prone and time consuming job.
What I don't get and what really f... me is that every developer on Mac has to do this by his own and that the Raspberry foundation doesn't provide these tools - gcc 4.9 is a joke - we need a modern compiler!!! like gcc 6.3)
A modern compiler won't solve the case-insensitivity problem, which is why we recommend using a virtual machine running Linux - I do.
I believe that the file system case sensitivity is optional, probably upon installation. You might be able to change it post installation.
I'm trying to build a large package on the Pi Zero running Raspbian Stretch, and I want to use distccd on a amd64 architecture Linux machine to help with the compilation. Having gcc 6.3.0 cross compiler would be incredibly useful.
This is definately an awful situation for many trying to modify the source of the firmware, but for 90% of the above you came to the wrong place.
If you are cross compiling apps for pi, you could just use the newest compiler you want, even gcc7 is okay. BUT WITH STATIC LINKING AND AN INDEPENDENTLY BUILT GCC. Like the one you built with --without-headers before compiling glibc(in the toolchain build). This is the best way almost, as the firmware of embedded systems update much slower even than the cpp standard, let alone the compiler.
You are mislead here because Debian packager knows nothing about this. The official debian arm-linux-gcc package is a stage two gcc, depending on a debian built glibc. It is limited to debian arm systems, and only works with the latest raspbian(with latest glibc).
Fedora is clearly smarter, so it shipped with the good gcc I described above.
Another thing is Debian has a clumsy multiarch dir structure, and it patches gcc to let it search different folders. If you find someting should be in /usr/lib end up in /usr/lib/arm-linux-gmueabihf, just copy it to where it should be, its okay.
@omegacoleman is right. It is really easy to build your own toolchain. If you link your application correct it will run without problems on the raspberry pi.
So if you came here because deployment on a armhf platform is your focus - and not a specific distribution (version) - you should look into building snaps with snapcraft.
If you build your application as a snap ABI troubles and finding the right compiler are no longer a problem. You basically build your software against a specific libc and libstdc++ ABI - but with a compiler of your choice - and you wont have further external dependencies that might not be available on the target system. On the target system the snap daemon will take care that the ABI is available - either through the underlying distribution or shipped with snapd.
A caveat: snapcraft by default does not cross compile. You usually assemble your application within a build container. But since 2017 cross compilation was added for many of the build plugins - autotools/make go rust.. CMake needs a workaround ). Alternatively you can let launchpad take care of building on armhf and arm64.
@APokorny snap can't run on Pi Zero because Ubuntu does not support ARMv6. Neither does Launchpad, nor the arm cross compilers in Debian and Ubuntu They all require a minimum of ARMv7.
In addition crosstool-ng seems incapable of building a Debian compatible cross toolchain due to this issue: https://github.com/crosstool-ng/crosstool-ng/issues/1055
I've managed to figure out how to build a working toolchain with both crosstool-ng and with Linaro ABE (which is their own custom build tool to replace ct-ng).
To get crosstool-ng working you just need to add "--enable-multiarch" to the GCC configuration options. However, ct-ng stable release has trouble compiling with the newest Ubuntu, and the development release is radically different to previous versions.
ABE has no such problems on modern Ubuntu releases. It also enables multiarch by default, which is why the Linaro binary releases can be used as long as you only target ARMv7. Getting it to build a toolchain for ARMv6 is actually quite easy to do: take the manifest from some ARMv7 release and directly edit the GCC config flags, then ask ABE to rebuild it. The result is this, which you can rebuild yourself:
https://github.com/ali1234/rpi-toolchain
or you can get binaries from the releases page:
https://github.com/ali1234/rpi-toolchain/releases
This toolchain is packaged the same way as the Linaro toolchain and can be directly dropped in to replace it. I'm using this toolchain in rpi-ramdisk now, and I have built Qt/QML and successfully run it on the Zero and 3B.
@ali1234 I cloned your repo then cloned abe (master branch).
I ran the build.sh script: It failed with:
...
RUN: /home/dom/projects/rpi-toolchain/_build/snapshots/dejagnu.git /home/dom/projects/rpi-toolchain/_build/snapshots/dejagnu.git~linaro-local_stable_rev_9c19d3d7473ef731b74f3a48fcce5a168bf701ec 9c19d3d7473ef731b74f3a48fcce5a168bf701ec
/home/dom/projects/rpi-toolchain/abe/lib/common.sh: line 64: /home/dom/projects/rpi-toolchain/_build/snapshots/dejagnu.git: Is a directory
WARNING: Previous command failed
ERROR (#172): checkout (Failed to create workdir for 9c19d3d7473ef731b74f3a48fcce5a168bf701ec)
ERROR (#54): checkout_all (Failed checkout out of dejagnu.)
ERROR (#118): perform_build_steps (Step CHECKOUT failed)
ERROR (#307): build_failure (Build process failed after 28 minutes)
Any ideas?
You should clone my repository with --recursive so that it clones and checks out the correct version of ABE. It is set up to use the exact same commit as was used to build the original manifest. I think the master branch of ABE is unstable.