GCC version not upgraded

[APokorny]

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.

[popcornmix]

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.

[carlonluca]

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.

[robiwano]

@carlonluca How did you build it ? Did you use crosstool-ng ?

[crapp]

@carlonluca please provide the build steps for your toolchain. I would like to build them myself

[carlonluca]

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

[MikeMitterer]

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.

[JamesH65]

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.

[robiwano]

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.

[JamesH65]

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.

[APokorny]

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

[MikeMitterer]

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

[JamesH65]

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.

[WayneKeenan]

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.

[MikeMitterer]

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

[jakemagee]

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.

[robiwano]

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.

[jakemagee]

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.

[johnmanko]

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

[MikeMitterer]

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

[pelwell]

A modern compiler won't solve the case-insensitivity problem, which is why we recommend using a virtual machine running Linux - I do.

[johnmanko]

I believe that the file system case sensitivity is optional, probably upon installation. You might be able to change it post installation.

[yoursunny]

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.

[omegacoleman]

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.

[crapp]

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

[APokorny]

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.

[ali1234]

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

[ali1234]

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

[ali1234]

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.

[popcornmix]

@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?

[ali1234]

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.

[ali1234]

Also abe configure should have asked you to install some things, at the very least you probably don't have git-new-workdir. I built on ubuntu 18.04 using only repo packages (git-new-workdir is packaged but has to be copied from /usr/share/doc to the path, the script tells you what to do iirc)

[popcornmix]

I've tried building from a --recursive clone but no change in behaviour. Tried on two machines with the same result.

[ali1234]

This is definitely an issue of missing git-new-workdir. It looks like the configure script doesn't exit with an error code if it finds a missing tool, so the script just continues on. You never see the error and then the build fails much later. In this case what is happeneing is $NEWWORKDIR is unset so instead of running the command it tries to run the directory, leading to the error you see. You should be able to confirm this by looking at _build/hosts.conf, which should have a line like NEWWORKDIR=/home/al/.local/bin/git-new-workdir or wherever you copied it. I expect it will be missing or empty...

[ali1234]

Okay I fixed it. I forgot to sh -e, so untested errors were ignored.

[popcornmix]

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. Kodi crashes after a few seconds with what looks like heap corruption. The 4.9 gcc doesn't have this problem.

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.

[ali1234]

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.

[popcornmix]

4.9 compiler works just fine for raspbian stretch. We use it to build the userland libs and apps (e.g. raspicam).

[popcornmix]

dom@dom-XPS-13-9370:/tmp$ arm-linux-gnueabihf-gcc --version
arm-linux-gnueabihf-gcc (crosstool-NG crosstool-ng-1.22.0-88-g8460611) 4.9.3
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

dom@dom-XPS-13-9370:/tmp$ arm-linux-gnueabihf-gcc hello.c 
dom@dom-XPS-13-9370:/tmp$ file a.out
a.out: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32, not stripped

and a.out runs fine on raspbian stretch.

[ali1234]

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 --sysroot /path/to/raspbian/root.

[popcornmix]

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 (--with-sysroot) to use raspbian's sysroot (i.e. include raspbian libs in the sysroot dir of toolchain), so explicitly using --sysroot on every compile isn't required. I didn't get this working - is that option something you are familiar with?

[ali1234]

The 4.9.3 compiler isn't compatible with Raspbian sysroots because it is built without --enable-multiarch. As such it won't find headers in the triplet prefixed directories that Debian and Raspbian use. It will refuse to compile even hello.c after it fails to find sys/cdefs.h.

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.

[popcornmix]

But the 4.9.3 toolchain is the only toolchain that works for everything. I use it to build raspbian kernel, raspian userland libs and apps and kodi and it just works.

Executables runs correctly on raspbian jessie and raspbian stretch.

I only have issues with newer versions of gcc.

[ali1234]

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.

[popcornmix]

This is how I build kodi. It's working on current kodi master (on ubuntu 18.10 with all required native dependencies installed)

MYADDONS="pvr.hts"
PREFIX=/home/dom/xbmc_holder/xbmc/build/install

set -e
    cd ~/xbmc_holder/xbmc/ \
    && \
    cd tools/depends \
    && \
    ./bootstrap \
    && \
    ./configure --host=arm-linux-gnueabihf \
        --prefix=${PREFIX} \
        --with-firmware=/opt/bcm-rootfs \
        --with-toolchain=/opt/arm-linux-gnueabihf \
        --with-platform=raspberry-pi2 \
    && \
    nice ionice make -j$(getconf _NPROCESSORS_ONLN) \
    && \
    cd ../.. \
    && \
    make -C tools/depends/target/cmakebuildsys \
    && \
    mkdir -p build && cd build \
    && \
    nice ionice make -j$(getconf _NPROCESSORS_ONLN) \
    && \
    make binary-addons ADDON_SRC_PREFIX=/home/dom/xbmc_holder ADDONS=$MYADDONS \
    && \
    make install

/opt/bcm-rootfs contains pi rootfs (I believe only used for /opt/vc/lib libs) /opt/arm-linux-gnueabihf is a symlink to current cross compiler (4.9.3 from tools repo)

[popcornmix]

And the kodi executable isn't static - it's using libs from /usr/lib and /lib of raspbian

pi@domnfs:/opt/xbmc $ ldd kodi-rbpi
    linux-vdso.so.1 (0x7edbf000)
    libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0x76ec1000)
    libEGL.so => /opt/vc/lib/libEGL.so (0x76e88000)
    libGLESv2.so => /opt/vc/lib/libGLESv2.so (0x76e63000)
    libbcm_host.so => /opt/vc/lib/libbcm_host.so (0x76e3c000)
    libvcos.so => /opt/vc/lib/libvcos.so (0x76e22000)
    libvchiq_arm.so => /opt/vc/lib/libvchiq_arm.so (0x76e0c000)
    libasound.so.2 => /usr/lib/arm-linux-gnueabihf/libasound.so.2 (0x76d1f000)
    libbluray.so.2 => not found
    libcec.so => not found
    libdbus-1.so.3 => /lib/arm-linux-gnueabihf/libdbus-1.so.3 (0x76ccc000)
    librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0x76cb5000)
    libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0x76ca2000)
    libutil.so.1 => /lib/arm-linux-gnueabihf/libutil.so.1 (0x76c8f000)
    libsmbclient.so.0 => /usr/lib/arm-linux-gnueabihf/libsmbclient.so.0 (0x76c5e000)
    libass.so.5 => /usr/lib/arm-linux-gnueabihf/libass.so.5 (0x76c29000)
    libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0x76baa000)
    libbrcmGLESv2.so => /opt/vc/lib/libbrcmGLESv2.so (0x76b85000)
    libbrcmEGL.so => /opt/vc/lib/libbrcmEGL.so (0x76b4c000)
    libmmal.so => /opt/vc/lib/libmmal.so (0x76b39000)
    libmmal_core.so => /opt/vc/lib/libmmal_core.so (0x76b1b000)
    libmmal_util.so => /opt/vc/lib/libmmal_util.so (0x76afb000)
    libmmal_vc_client.so => /opt/vc/lib/libmmal_vc_client.so (0x76ae0000)
    libmmal_components.so => /opt/vc/lib/libmmal_components.so (0x76ac5000)
    libvcsm.so => /opt/vc/lib/libvcsm.so (0x76ab0000)
    libcontainers.so => /opt/vc/lib/libcontainers.so (0x76a8f000)
    libinput.so.10 => /usr/lib/arm-linux-gnueabihf/libinput.so.10 (0x76a57000)
    libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x76918000)
    /lib/ld-linux-armhf.so.3 (0x76f00000)
    libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0x767d0000)
    libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0x767a3000)
    libsystemd.so.0 => /lib/arm-linux-gnueabihf/libsystemd.so.0 (0x76729000)
    libsamba-util.so.0 => /usr/lib/arm-linux-gnueabihf/libsamba-util.so.0 (0x766ad000)
    libtalloc-report.so.0 => /usr/lib/arm-linux-gnueabihf/samba/libtalloc-report.so.0 (0x7669a000)
    libtevent-util.so.0 => /usr/lib/arm-linux-gnueabihf/libtevent-util.so.0 (0x76687000)
    liblibsmb.so.0 => /usr/lib/arm-linux-gnueabihf/samba/liblibsmb.so.0 (0x7661f000)
    libmsrpc3.so.0 => /usr/lib/arm-linux-gnueabihf/samba/libmsrpc3.so.0 (0x765f3000)
    libsamba-errors.so.1 => /usr/lib/arm-linux-gnueabihf/libsamba-errors.so.1 (0x764f7000)
    liblibcli-lsa3.so.0 => /usr/lib/arm-linux-gnueabihf/samba/liblibcli-lsa3.so.0 (0x764e3000)
    libsamba-security.so.0 => /usr/lib/arm-linux-gnueabihf/samba/libsamba-security.so.0 (0x764bb000)
    libsmbconf.so.0 => /usr/lib/arm-linux-gnueabihf/libsmbconf.so.0 (0x76444000)
    libsamba3-util.so.0 => /usr/lib/arm-linux-gnueabihf/samba/libsamba3-util.so.0 (0x7642c000)
    libndr.so.0 => /usr/lib/arm-linux-gnueabihf/libndr.so.0 (0x7640a000)
    libsamba-debug.so.0 => /usr/lib/arm-linux-gnueabihf/samba/libsamba-debug.so.0 (0x763f5000)
    libcli-smb-common.so.0 => /usr/lib/arm-linux-gnueabihf/samba/libcli-smb-common.so.0 (0x763c1000)
    libgse.so.0 => /usr/lib/arm-linux-gnueabihf/samba/libgse.so.0 (0x7638e000)
    libutil-cmdline.so.0 => /usr/lib/arm-linux-gnueabihf/samba/libutil-cmdline.so.0 (0x7637b000)
    libndr-standard.so.0 => /usr/lib/arm-linux-gnueabihf/libndr-standard.so.0 (0x760a5000)
    libdcerpc-samba.so.0 => /usr/lib/arm-linux-gnueabihf/samba/libdcerpc-samba.so.0 (0x75f54000)
    libsmbregistry.so.0 => /usr/lib/arm-linux-gnueabihf/samba/libsmbregistry.so.0 (0x75f2b000)
    libsecrets3.so.0 => /usr/lib/arm-linux-gnueabihf/samba/libsecrets3.so.0 (0x75f12000)
    libbsd.so.0 => /lib/arm-linux-gnueabihf/libbsd.so.0 (0x75ee9000)
    libtalloc.so.2 => /usr/lib/arm-linux-gnueabihf/libtalloc.so.2 (0x75ec7000)
    libtevent.so.0 => /usr/lib/arm-linux-gnueabihf/libtevent.so.0 (0x75eaa000)
    libfribidi.so.0 => /usr/lib/arm-linux-gnueabihf/libfribidi.so.0 (0x75e83000)
    libfontconfig.so.1 => /usr/lib/arm-linux-gnueabihf/libfontconfig.so.1 (0x75e40000)
    libfreetype.so.6 => /usr/lib/arm-linux-gnueabihf/libfreetype.so.6 (0x75da5000)
    libharfbuzz.so.0 => /usr/lib/arm-linux-gnueabihf/libharfbuzz.so.0 (0x75d0e000)
    libmtdev.so.1 => /usr/lib/arm-linux-gnueabihf/libmtdev.so.1 (0x75d01000)
    libudev.so.1 => /lib/arm-linux-gnueabihf/libudev.so.1 (0x75ce4000)
    libevdev.so.2 => /usr/lib/arm-linux-gnueabihf/libevdev.so.2 (0x75cc4000)
    libwacom.so.2 => /usr/lib/arm-linux-gnueabihf/libwacom.so.2 (0x75cab000)
    libselinux.so.1 => /lib/arm-linux-gnueabihf/libselinux.so.1 (0x75c78000)
    liblzma.so.5 => /lib/arm-linux-gnueabihf/liblzma.so.5 (0x75c47000)
    liblz4.so.1 => /usr/lib/arm-linux-gnueabihf/liblz4.so.1 (0x75c26000)
    libgcrypt.so.20 => /lib/arm-linux-gnueabihf/libgcrypt.so.20 (0x75b53000)
    libtime-basic.so.0 => /usr/lib/arm-linux-gnueabihf/samba/libtime-basic.so.0 (0x75b41000)
    libsocket-blocking.so.0 => /usr/lib/arm-linux-gnueabihf/samba/libsocket-blocking.so.0 (0x75b2f000)
    libgenrand.so.0 => /usr/lib/arm-linux-gnueabihf/samba/libgenrand.so.0 (0x75b1d000)
    libkrb5samba.so.0 => /usr/lib/arm-linux-gnueabihf/samba/libkrb5samba.so.0 (0x75b02000)
    libcli-cldap.so.0 => /usr/lib/arm-linux-gnueabihf/samba/libcli-cldap.so.0 (0x75aeb000)
    libcliauth.so.0 => /usr/lib/arm-linux-gnueabihf/samba/libcliauth.so.0 (0x75acb000)
    libsys-rw.so.0 => /usr/lib/arm-linux-gnueabihf/samba/libsys-rw.so.0 (0x75ab8000)
    libgensec.so.0 => /usr/lib/arm-linux-gnueabihf/samba/libgensec.so.0 (0x75a85000)
    libcom_err-samba4.so.0 => /usr/lib/arm-linux-gnueabihf/samba/libcom_err-samba4.so.0 (0x75a72000)
    libasn1util.so.0 => /usr/lib/arm-linux-gnueabihf/samba/libasn1util.so.0 (0x75a5b000)
    libndr-nbt.so.0 => /usr/lib/arm-linux-gnueabihf/libndr-nbt.so.0 (0x75a38000)
    libsamba-hostconfig.so.0 => /usr/lib/arm-linux-gnueabihf/libsamba-hostconfig.so.0 (0x75a0a000)
    libsmb-transport.so.0 => /usr/lib/arm-linux-gnueabihf/samba/libsmb-transport.so.0 (0x759f5000)
    libsamba-credentials.so.0 => /usr/lib/arm-linux-gnueabihf/libsamba-credentials.so.0 (0x759d6000)
    libCHARSET3.so.0 => /usr/lib/arm-linux-gnueabihf/samba/libCHARSET3.so.0 (0x759c3000)
    libndr-samba.so.0 => /usr/lib/arm-linux-gnueabihf/samba/libndr-samba.so.0 (0x758a7000)
    libdbwrap.so.0 => /usr/lib/arm-linux-gnueabihf/samba/libdbwrap.so.0 (0x7588e000)
    libdcerpc-binding.so.0 => /usr/lib/arm-linux-gnueabihf/libdcerpc-binding.so.0 (0x75865000)
    libutil-tdb.so.0 => /usr/lib/arm-linux-gnueabihf/samba/libutil-tdb.so.0 (0x75852000)
    libsamba-sockets.so.0 => /usr/lib/arm-linux-gnueabihf/samba/libsamba-sockets.so.0 (0x7582d000)
    libinterfaces.so.0 => /usr/lib/arm-linux-gnueabihf/samba/libinterfaces.so.0 (0x7581a000)
    libmessages-dgm.so.0 => /usr/lib/arm-linux-gnueabihf/samba/libmessages-dgm.so.0 (0x75802000)
    libserver-id-db.so.0 => /usr/lib/arm-linux-gnueabihf/samba/libserver-id-db.so.0 (0x757ef000)
    libiov-buf.so.0 => /usr/lib/arm-linux-gnueabihf/samba/libiov-buf.so.0 (0x757dd000)
    libutil-reg.so.0 => /usr/lib/arm-linux-gnueabihf/samba/libutil-reg.so.0 (0x757cb000)
    libmessages-util.so.0 => /usr/lib/arm-linux-gnueabihf/samba/libmessages-util.so.0 (0x757b9000)
    libsmbd-shim.so.0 => /usr/lib/arm-linux-gnueabihf/samba/libsmbd-shim.so.0 (0x757a7000)
    libutil-setid.so.0 => /usr/lib/arm-linux-gnueabihf/samba/libutil-setid.so.0 (0x75795000)
    libtdb-wrap.so.0 => /usr/lib/arm-linux-gnueabihf/samba/libtdb-wrap.so.0 (0x75782000)
    libserver-role.so.0 => /usr/lib/arm-linux-gnueabihf/samba/libserver-role.so.0 (0x7576e000)
    libnsl.so.1 => /lib/arm-linux-gnueabihf/libnsl.so.1 (0x7574a000)
    libtdb.so.1 => /usr/lib/arm-linux-gnueabihf/libtdb.so.1 (0x75727000)
    libcap.so.2 => /lib/arm-linux-gnueabihf/libcap.so.2 (0x75712000)
    liblber-2.4.so.2 => /usr/lib/arm-linux-gnueabihf/liblber-2.4.so.2 (0x756f6000)
    libldap_r-2.4.so.2 => /usr/lib/arm-linux-gnueabihf/libldap_r-2.4.so.2 (0x756a1000)
    libkrb5-samba4.so.26 => /usr/lib/arm-linux-gnueabihf/samba/libkrb5-samba4.so.26 (0x7563e000)
    libaddns.so.0 => /usr/lib/arm-linux-gnueabihf/samba/libaddns.so.0 (0x75625000)
    libgssapi-samba4.so.2 => /usr/lib/arm-linux-gnueabihf/samba/libgssapi-samba4.so.2 (0x755f0000)
    libauthkrb5.so.0 => /usr/lib/arm-linux-gnueabihf/samba/libauthkrb5.so.0 (0x755c9000)
    libcli-nbt.so.0 => /usr/lib/arm-linux-gnueabihf/samba/libcli-nbt.so.0 (0x755ae000)
    libmsghdr.so.0 => /usr/lib/arm-linux-gnueabihf/samba/libmsghdr.so.0 (0x7559c000)
    libexpat.so.1 => /lib/arm-linux-gnueabihf/libexpat.so.1 (0x7556a000)
    libz.so.1 => /lib/arm-linux-gnueabihf/libz.so.1 (0x75543000)
    libpng16.so.16 => /usr/lib/arm-linux-gnueabihf/libpng16.so.16 (0x75509000)
    libglib-2.0.so.0 => /lib/arm-linux-gnueabihf/libglib-2.0.so.0 (0x75401000)
    libgraphite2.so.3 => /usr/lib/arm-linux-gnueabihf/libgraphite2.so.3 (0x753ce000)
    libgudev-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgudev-1.0.so.0 (0x753b6000)
    libgobject-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0 (0x7535c000)
    libpcre.so.3 => /lib/arm-linux-gnueabihf/libpcre.so.3 (0x752e1000)
    libgpg-error.so.0 => /lib/arm-linux-gnueabihf/libgpg-error.so.0 (0x752c1000)
    libasn1-samba4.so.8 => /usr/lib/arm-linux-gnueabihf/samba/libasn1-samba4.so.8 (0x75256000)
    libcli-ldap-common.so.0 => /usr/lib/arm-linux-gnueabihf/samba/libcli-ldap-common.so.0 (0x7523f000)
    libwinbind-client.so.0 => /usr/lib/arm-linux-gnueabihf/samba/libwinbind-client.so.0 (0x7522c000)
    libldb.so.1 => /usr/lib/arm-linux-gnueabihf/libldb.so.1 (0x751f5000)
    libwbclient.so.0 => /usr/lib/arm-linux-gnueabihf/libwbclient.so.0 (0x751d9000)
    libsamba-modules.so.0 => /usr/lib/arm-linux-gnueabihf/samba/libsamba-modules.so.0 (0x751c6000)
    libsamdb.so.0 => /usr/lib/arm-linux-gnueabihf/libsamdb.so.0 (0x751a1000)
    libsamdb-common.so.0 => /usr/lib/arm-linux-gnueabihf/samba/libsamdb-common.so.0 (0x75169000)
    libldbsamba.so.0 => /usr/lib/arm-linux-gnueabihf/samba/libldbsamba.so.0 (0x75135000)
    libresolv.so.2 => /lib/arm-linux-gnueabihf/libresolv.so.2 (0x75110000)
    libsasl2.so.2 => /usr/lib/arm-linux-gnueabihf/libsasl2.so.2 (0x750e9000)
    libgnutls.so.30 => /usr/lib/arm-linux-gnueabihf/libgnutls.so.30 (0x74f5c000)
    libheimbase-samba4.so.1 => /usr/lib/arm-linux-gnueabihf/samba/libheimbase-samba4.so.1 (0x74f49000)
    libhx509-samba4.so.5 => /usr/lib/arm-linux-gnueabihf/samba/libhx509-samba4.so.5 (0x74f05000)
    libhcrypto-samba4.so.5 => /usr/lib/arm-linux-gnueabihf/samba/libhcrypto-samba4.so.5 (0x74eca000)
    libroken-samba4.so.19 => /usr/lib/arm-linux-gnueabihf/samba/libroken-samba4.so.19 (0x74eaf000)
    libwind-samba4.so.0 => /usr/lib/arm-linux-gnueabihf/samba/libwind-samba4.so.0 (0x74e75000)
    libndr-krb5pac.so.0 => /usr/lib/arm-linux-gnueabihf/libndr-krb5pac.so.0 (0x74e5a000)
    libauth-sam-reply.so.0 => /usr/lib/arm-linux-gnueabihf/samba/libauth-sam-reply.so.0 (0x74e46000)
    libgio-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgio-2.0.so.0 (0x74ce2000)
    libffi.so.6 => /usr/lib/arm-linux-gnueabihf/libffi.so.6 (0x74cca000)
    libflag-mapping.so.0 => /usr/lib/arm-linux-gnueabihf/samba/libflag-mapping.so.0 (0x74cb8000)
    libp11-kit.so.0 => /usr/lib/arm-linux-gnueabihf/libp11-kit.so.0 (0x74c5a000)
    libidn.so.11 => /lib/arm-linux-gnueabihf/libidn.so.11 (0x74c19000)
    libtasn1.so.6 => /usr/lib/arm-linux-gnueabihf/libtasn1.so.6 (0x74bf7000)
    libnettle.so.6 => /usr/lib/arm-linux-gnueabihf/libnettle.so.6 (0x74bb0000)
    libhogweed.so.4 => /usr/lib/arm-linux-gnueabihf/libhogweed.so.4 (0x74b73000)
    libgmp.so.10 => /usr/lib/arm-linux-gnueabihf/libgmp.so.10 (0x74b00000)
    libgmodule-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgmodule-2.0.so.0 (0x74aec000)
    libmount.so.1 => /lib/arm-linux-gnueabihf/libmount.so.1 (0x74a99000)
    libblkid.so.1 => /lib/arm-linux-gnueabihf/libblkid.so.1 (0x74a4c000)
    libuuid.so.1 => /lib/arm-linux-gnueabihf/libuuid.so.1 (0x74a38000)

[ali1234]

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.

[popcornmix]

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?

[ali1234]

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.

[jslauthor]

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

[ghost]

@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:

Checking for OpenGL ES 2.0... 
Trying source 0 (type pkgConfig) of library opengl_es2 ...
+ PKG_CONFIG_SYSROOT_DIR=/home/mark/opt/sysroot PKG_CONFIG_LIBDIR=/home/mark/opt/sysroot/usr/lib/pkgconfig:/home/mark/opt/sysroot/usr/share/pkgconfig:/home/mark/opt/sysroot/usr/lib/arm-linux-gnueabihf/pkgconfig /usr/bin/pkg-config --exists --silence-errors glesv2
pkg-config did not find package.
  => source produced no result.
Trying source 1 (type makeSpec) of library opengl_es2 ...
header entry 'config.qtbase_gui.libraries.opengl_es2.headers.0' passed condition.
GLES2/gl2.h not found in [] and global paths.
  => source produced no result.
test config.qtbase_gui.libraries.opengl_es2 FAILED

I've copied the /opt/vc/ libraries to /home/mark/opt/sysroot/usr/.