GCC version not upgraded #81
Comments
|
I have been testing a newer gcc but unfortunately it failed testing. |
|
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 How did you build it ? Did you use crosstool-ng ? |
|
@carlonluca please provide the build steps for your toolchain. I would like to build them myself |
|
Developer support is incredible bad! |
|
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. |
|
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. |
|
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...
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. |
|
Also |
|
I've tried building from a --recursive clone but no change in behaviour. Tried on two machines with the same result. |
|
This is definitely an issue of missing |
|
Okay I fixed it. I forgot to sh -e, so untested errors were ignored. |
|
Thanks - build completes now. I'm still not sure I trust the compiler though. Basically all my attempts to bump to gcc 6 (and this also applies to this new build) fail to compile a usable kodi build. Now it's possible there is a bug in kodi that somehow 4.9 doesn't trigger (and hasn't been observed on the many other platforms) but I went through the process of commenting out areas of code that were in the crashing callstack, and would always find another crash a bit later in unrelated code. I've not seen an issue with building the kernel or userland libs with newer compilers, so far I've only seen the problem in kodi. I wonder if there could be difference in libc or some brokenness in atomics that makes malloc/free not thread safe when building with newer gcc. |
|
Can you please describe how you're building and running Kodi wth both compilers? Because as far as I am concerned the 4.9 compiler isn't capable of producing binaries that can run on Raspbian at all... not even hello world should work, it shouldn't even finish compiling. |
|
4.9 compiler works just fine for raspbian stretch. We use it to build the userland libs and apps (e.g. raspicam). |
and a.out runs fine on raspbian stretch. |
|
Where is your sysroot? You are building against the libraries in the default toolchain sysroot. If they don't perfectly match Raspbian you will get segfaults. This works with glibc because it has a stable ABI but the same is not true for all Kodi dependencies. In order to actually build against Raspbian you need to specify |
|
Lets see if I get kodi to build with an explicit sysroot set. The existing compiler has a sysroot directory: https://github.com/raspberrypi/tools/tree/master/arm-bcm2708/arm-rpi-4.9.3-linux-gnueabihf/arm-linux-gnueabihf/sysroot I believe it should be possible to configure gcc build ( |
|
The 4.9.3 compiler isn't compatible with Raspbian sysroots because it is built without ABE and ct-ng both claim to be able to build gcc against an existing sysroot which would mean you could build a toolchain on top of the real Raspbian glibc, however neither of them actually documents how to do this and I haven't managed to figure it out yet. |
|
But the 4.9.3 toolchain is the only toolchain that works for everything. Executables runs correctly on raspbian jessie and raspbian stretch. I only have issues with newer versions of gcc. |
|
Well, you still haven't said how you're building Kodi. The cross compile instructions they have tell you to use 4.9.3 and their build system compiles every dependency from scratch. So you are not building it for Raspbian if you do it that way. You're effectively building a cross-distribution bundle. The instructions also currently don't work - it fails to build libudev with "R_ARM_TLS_LE32 relocation not permitted in shared object" with both 4.9.3 compiler and my own compiler. The kernel of course doesn't care what userspace libraries are in your sysroot because it doesn't use any of them at all - you can build it with a arm-none-gnueabihf bare metal compiler. |
|
This is how I build kodi. It's working on current kodi master (on ubuntu 18.10 with all required native dependencies installed) /opt/bcm-rootfs contains pi rootfs (I believe only used for /opt/vc/lib libs) |
|
And the kodi executable isn't static - it's using libs from /usr/lib and /lib of raspbian |
|
Yes, this is the cause of all your problems. Your build script is the same as the upstream instructions. The first time you run make it is to build all the dependencies of Kodi from source. The next steps then build Kodi against those libraries. Then you run it against the Raspbian system libraries, which are different. If this works at all, it's because of luck. If you get segfaults and memory corruption it is because the library ABIs do not match. You should set up the library path to make Kodi use the libraries it was built against, then it will work. Alternatively build it against a real Raspbian sysroot - but this is not possible with the 4.9.3 compiler. |
|
But most of these libs aren't built by kodi depends. Kodi doesn't attempt to build libc/libm/librt/libdl/libpthread. Won't this be an issue when the compiler doesn't know what versions of these are being used at runtime? |
|
Yes, it is a problem. To be really sure it works you also have to install the compiler default runtime since that it what you built against. The Linaro toolchains are split into three packages for this reason: gcc, sysroot, and runtime. The sysroot is the development headers and the runtime is just what you need when running programs. You can normally get away with using slightly different versions of core libraries like glibc/pthreads because that stuff is really stable and they put loads of work into being backwards compatible. But the further you get from the core platform, the less likely it is to work. |
|
@ali1234 I really can't thank you enough. I've been struggling to cross-compile Qt 5.12.0 with EGLFS for longer than I care to admit 😅 but using your build script to compile the newer GCC finally got me to the finish line. I'm in awe watching my app on a 7" LCD hum along, running shaders at 60fps without X11. 🙇 |
|
@jslauthor might you share some details? I'm still trying to cross-compile Qt5.13 with EGLFS for Rpi3B+vc4 using the newer linaro-gcc toolchain suggested by @ali1234. I have a fresh Raspbian Lite environment (still in a loop device) where I downloaded dependencies (build-dep qt5-default, libssl1.0-dev libudev-dev libinput-dev libdbus-1-dev libglib2.0-dev libts-dev libx11-dev libx11-xcb-dev libxi-dev libasound2-dev fonts-dejavu gdbserver gdb-python2), sync-ed the sysroot with the out provided by the linaro toolchain. But the configure tool of Qt5 doesn't find any EGLFS/OpenGL library: I've copied the |
|
@Mark-81 Qt won't find the pkg-config files because of complicated reasons. I ended up writing a custom build tool (https://github.com/ali1234/pydo/) to manage all the ever growing list of workarounds in https://github.com/ali1234/rpi-ramdisk. In addition to the final ramdisk target it produces tgz files with the runtime libraries which you can just unpack on regular raspbian and add to the ld config. It constructs the sysroot directly from debs using multistrap and then applies all the workarounds. It downloads my abe toolchain binary releases from github. Then it builds the kernel (twice) and all the selected packages (eg Qt, gstreamer etc). You also get a qt-host directory that you can use for cross compiling outside rpi-ramdisk. qmake from that dir will set up the environment to compile against the rpi-ramdisk sysroot. It does produce Qt EGLFS executables that run on Pi Zero, but they are a bit slow compared to Pi 3. |
|
@ali1234 thanks for your explanation and your effort! I'm not interested in Pi Zero, but I just want to have a decent performance (using GPU) for RPi3B+ without X and with QML enabled, at least Qt5.12. I give it a try to your |
ghost
mentioned this issue
|
@Mark-81 hopefully @ali1234's advice helped. I couldn't get 5.13 to compile. 🙁I compiled 5.12.0 successfully. Would love to know if you are successful with 5.13, however, since Lottie integration is an awesome new feature! |
|
@jslauthor unfortunately not: ali1234/rpi-ramdisk#14 I spent too much time and for now I'm stuck with the old Qt 5.9.
At least we should have a working configuration. I understand that cannot cover all the needs for everyone, but there would be one reliable scenario to start with. |
|
I have updated my toolchain to include the binutils multiarch patch (see #102 (comment)). In order to do this I had to go back to using crosstool-ng. Adding multiarch support to binutils allowed me to remove the It also lead me to rediscover a bug in Debian libtool from 2005 that prevents cross-compiling some projects. I set the crosstool-ng to put a vanilla libtool in the toolchain. It will avoid the bug, but causes some overlinking. This isn't a really problem unless you are building inter-dependent debs. Either way, this is something that Debian needs to fix, but probably never will. I think this is the best recipe yet - having proper multiarch support is something that even the original Linaro compiler never had as far as I can tell. I also made the scripts so it can be built inside Docker, although in the process I ran in to moby/moby#13451 (but this doesn't prevent the build from working, it just prevents cleaning up the container afterwards.) Toolchain is here: https://github.com/ali1234/rpi-toolchain |
|
I created a new repository which contains an updated toolchain with ARMv6 support. Tested it on a Raspberry PI Zero with Raspbian Buster, and it works perfectly. See: And the repo: I'm happy for any feedback. |
|
@Pro your toolchain has no multiarch support so it will not correctly link against Raspbian libraries. Configure gcc with multiarch support and apply the binutils patch from my repository to fix this. To make it relocatable, built the dependencies static and configure everything with sysroot support. |
|
I also recommend stripping everything and removing unnecessary files as it will save over a gigabyte of space. |
|
Attached, my notes on how Linaro ABE configures each component to achieve a relocatable system: I've switched away from ABE back to crosstool-ng now because it was too hard to get ABE to apply the binutils patch (mainly because Linaro deleted all the public documentation about ABE.) |
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.
The text was updated successfully, but these errors were encountered: