Build: Testing switch to GCC 5.2

[ThomasKaiser]

Sorry, this is really my last one before I'm off a bit.

As already outlined switching to GCC 5.2 isn't that hard. All you need is to untar Linaro's toolchain somewhere and to prefix $PATH with the location.

I tried a few builds with 5.2 and it worked. So maybe it would be a good idea if we devs increase GCC version number for our daily tests and if everything's ok, consider switching to 5.2 with the whole build system?

[zador-blood-stained]

Cubieboard 1 legacy kernel (sun4i) compilation was broken, if I remember correctly (With Ubuntu GCC 5.x).

[ThomasKaiser]

Can confirm that (3.4 for A10):

  LD      init/mounts.o                                                  
init/do_mounts_rd.o: In function `return_address':                       
do_mounts_rd.c:(.text+0x0): multiple definition of `return_address'      
init/do_mounts.o:do_mounts.c:(.text+0x34): first defined here            
init/do_mounts_initrd.o: In function `return_address':                   
do_mounts_initrd.c:(.text+0x0): multiple definition of `return_address'  
init/do_mounts.o:do_mounts.c:(.text+0x34): first defined here            
make[1]: *** [init/mounts.o] Error 1                                     
make: *** [init] Error 2 

[zador-blood-stained]

I believe this error can be fixed with this simple patch, after that it needs testing whether it's the only problem.

[ThomasKaiser]

Ok, will look into it when I'm back. But I fear i will adjust the build system a bit before since I always forget to increase verbosity or redirecting progress into files (goal: log as much as possible, if build succeeds throw logs aways otherwise print a message on stderr where to look into).

But this will take some time...

[zador-blood-stained]

If we are collecting broken things, makefile arch\arm\plat-sunxi\pm\standby\Makefile is broken for Ubuntu complier (throwing away -fno-stack-protector option)

(goal: log as much as possible, if build succeeds throw logs aways otherwise print a message on stderr where to look into).

PROGRESS_LOG_TO_FILE=yes turns on logging to file for all compilation output, or are you testing standalone toolchain outside of build script?

[ThomasKaiser]

Exactly: it's setting _PROGRESS_LOG_TO_FILE=yes_ I always forget (even to add it my profile). I wanted to take some time to look deeper into it (then also checking _debootstrap-ng.sh_ to not always ask dumb questions) and then look into the build_all.sh stuff too. But first I want/need to setup the new build host (still no decision whether I run Ubuntu on the hardware or try to go with ESXi 4.x instead -- my host is not supported by 5.x unfortunately). As already said: this will take some time before I touch this...

[zador-blood-stained]

I made patches for makefile for sun4i and return_address problem, now realtek drivers (at least rtl8188eu and rtl8712) are broken for gcc5.

Update: I had to disable these to successfully compile sun7i legacy kernel with GCC5.

# CONFIG_RTL8192CU_SW is not set
# CONFIG_RTL8188EU is not set
# CONFIG_RTL8189ES is not set
# CONFIG_RTL8723AS is not set
# CONFIG_R8712U is not set

Update 2: same for sun4i

Update 3: sun8i default compiles successfully without any patches.

[igorpecovnik]

But we can't disable those drivers by default. Shell we just put a note if gcc5 is used - "Some legacy kernel drivers could fail to compile" and link here?

[zador-blood-stained]

They can be fixed (or we can compile and install them separately "out of tree"). But since this topic is called "Testing switch to GCC 5.2" I'm doing exactly this - testing and collecting broken stuff. I won't push any changes to kernel configs since Xenial isn't released yet and recommended build host OS is still Trusty.
I tested compilation in Trusty container, and GCC5 compatibility patches don't break compilation with older compiler, so at least this part should be fixed.

[zador-blood-stained]

Compilation of sun4i and sun7i legacy kernels with GCC 5 and current configs works now.

[ThomasKaiser]

Great work (as usual)! :) Thx for the update too.

[igorpecovnik]

Great! And we can close the issue.

[zador-blood-stained]

@igorpecovnik It can be closed for now, but sun5i and legacy kernels for non-sunxi devices may need some fixing later.

[igorpecovnik]

Marvell Uboot breaks

[zador-blood-stained]

I checked marvell u-boot compilation with GCC 5 and for now it doesn't look very promising. I'll try it again later when I have more time.

[ThomasKaiser]

I wouldn't invest that much time into it since it's absolutely ok to use different GCC versions for u-boot and kernel (for example Allwinner's BSP u-boot for Pine64 can not be built with anything above 4.8 and the kernel tree modified by longsleep not with any version less than 5.2)

On my new build host it looks like this:

root@armbian:/usr/local# du -sh gcc-linaro-*
865M    gcc-linaro-4.9-2015.05-x86_64_arm-linux-gnueabihf
979M    gcc-linaro-5.2-2015.11-1-x86_64_aarch64-linux-gnu
885M    gcc-linaro-5.2-2015.11-1-x86_64_arm-linux-gnueabihf

Relying on the Linaro toolchain as part of the build process (checking existence of needed toolchain, downloading/unpacking it when not available) could a) allow switching between different GCC versions to differentiate between u-boot/kernel build and b) help to standardize the build environment for all users (some might try to use Armbian on a system where for whatever reasons GCC 4.7 is present and report then errors that are hard to reproduce since the other devs use 4.9/5.2 instead).

[zador-blood-stained]

(some might try to use Armbian on a system where for whatever reasons GCC 4.7 is present and report then errors that are hard to reproduce since the other devs use 4.9/5.2 instead).

Hard to reproduce until you get lsb_release output from debug.log (from here), then you can ask to switch to a tested compilation environment.

Anyway I agree that using linaro toolchains (and activating them by modifying $PATH for compilation process) should be more or less universal solution to deal with different compiler versions.

[ThomasKaiser]

Hard to reproduce until you get lsb_release output from debug.log (from here)

That's the reason I added /proc/version output to armhwinfo.log --> 2nd line

@igorpecovnik what's your opinion on making Linaro toolchains mandatory and being able to choose the one that's appropriate for the build target in question?

[igorpecovnik]

I would say bringing and fixing code to work with 5+ compiler is nothing urgent at the moment. Further, there will always be some exotic BSP which will requre some odd compiler. Simple choice is to use it rather to adjust code. OK, it depends.

Pine64 uboot. I hope mainline will be ready soon so we won't need to fiddle with AW stuff.

You mean "USING_LINARO_COMPILER" and "YES" by default ? I would prefer GNU all the way if possible.

What do we gain if we use Linaro's tool chain?

[zador-blood-stained]

You mean "USING_LINARO_COMPILER" and "YES" by default ? I would prefer GNU all the way if possible.

More like defining compiler version for each family that supports only one compiler version (4.x/5.x) and defining path to specific linaro toolchains in lib.config by user.

[igorpecovnik]

OK, fine with me.

[ThomasKaiser]

Pine64 uboot. I hope mainline will be ready soon so we won't need to fiddle with AW stuff.

Unless mainline u-boot is ready we can't support Pine64 since we won't violate the GPL (and that happens when relying on Allwinner's BSP due to RAM initialisation done in a BLOB)

I see the following problem since when switching to Xenial as build host you automagically run into the inability to build marvell u-boot due to

root@armbian:~# gcc --version
gcc (Ubuntu 5.3.1-11ubuntu1) 5.3.1 20160311

What about defining SafePATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin and setting PATH=$SafePATH in configuration.sh and GCC4_PATH and GCC5_PATH being empty by default and 'tagging' specific build targets with eg. NEED_GCC4 or NEED_GCC5. If $NEED_GCC4=yes then check default GCC version and if 5.x and $GCC4_PATH is an empty string then stop compilation. Otherwise do a PATH=$GCC4_PATH:$SafePATH and proceed with this build step.

So users could adjust $SafePATH in lib.config to define another GCC to be used than the default one and also define the paths to either Linaro toolchains or experimental GCC builds they did on their own?

IMO moving to Xenial as preferred build environment has a few advances regarding the stuff I suggested in two other issues (multiple FEL boots, image 'personalisation' as last step of the build process)

[ThomasKaiser]

BTW: It get's even worse. Compiling u-boot for ODROID-C1 requires GCC 4.8 and fails with 4.9 already :)

[igorpecovnik]

So we need to cool down a little :) It's little harder to get everything under one hood.

[zador-blood-stained]

Initial support for switching toolchains: https://github.com/zador-blood-stained/lib/commit/42eb7a1fac1db4bd492cd5e33d109cb48675d109
Hope I didn't break anything :smile:

[zador-blood-stained]

BTW: It get's even worse. Compiling u-boot for ODROID-C1 requires GCC 4.8 and fails with 4.9 already :)

and precompiled linaro 4.8 toolchain is 32-bit only, while 4.9 and newer versions are 64-bit only :smile:

BTW Are there any other known compiler version requirements?