(10-18-2018, 05:31 PM)dukla2000 Wrote: [ -> ]Actually one thing I have noticed since upgrading to Cosmic is the compiler seems a little bit more chatty. I guess it is a newer version of gcc, and it is checking more. And while 4.18 and 4.19 compiles just have warnings (in colour!) 4.4 has outright fails.
Since gcc 7 its more verbose...
gcc 8 is even more verbose..
I was looking better at it,
memcmp(&vdso_start, "\177ELF", 4) is comparing vdso_start with some string...but vdso_start is null
Basically memcmp, is trying to check if vdso_start, is a Binary...but it is NULL.
This "warning" is caused by inappropriate description of the original "vdso.c" code
This is evident from the corresponding code being modified in "mainline-kernel".
There was no warning in "gcc-7", but since "gcc-8" is more strict checking,
I think that it will be issued as "warning".
In "kernel-build", even if it is "warning", depending on its kind, it treats as "fatal-error".
So I think that the build is failed.
Please see below for specific correction details.
"nds32: Fix compiler warning, "Wstringop-overflow=", in vdso.c"
https://code.forksand.com/linux/linux_ke...8166cca3ae
---
In my "gcc-8 (8.2.0)", "warning" did not come out, so I think that there is a version dependency.
(I think that it is better to output this as "warning")
And, as i usually use "gcc-7", I do not use "gcc-8" for "kernel-build".
Therefore, I will not pursue this subject any further.
It's not just the "warning" in vdso.c. With gcc-8 I get a -Wsizeof-pointer-memaccess in fs/exec.c.
patch here:
https://patchwork.kernel.org/patch/10090569/
oh and -Wstringop-truncation in fs/configfs/symlink.c and so on.
better stay with gcc-7.
(10-19-2018, 01:47 AM)hunderteins Wrote: [ -> ]better stay with gcc-7.
I still have 7 & 8 installed - is there a simple way to get my make for a 4.4 kernel use v7? A command line option, or temporary environment variable?
Inside the kernel tree:
$ CC=gcc-7 make -j6 Image
(10-19-2018, 09:14 AM)hunderteins Wrote: [ -> ]Inside the kernel tree:
$ CC=gcc-7 make -j6 Image
Same problem, so I tried
Code:
$ CC=gcc-7 make V=1 -j6 bindeb-pkg
To get some more info. Not sure if this is just 1 line from the log but still seems to be using bits of v8
Code:
./scripts/gcc-wrapper.py gcc -Wp,-MD,kernel/.configs.o.d -nostdinc -isystem /usr/lib/gcc/aarch64-linux-gnu/8/include -nostdinc -isystem /usr/lib/gcc/aarch64-linux-gnu/8/include -I./arch/arm64/include -Iarch/arm64/include/generated/uapi -Iarch/arm64/include/generated -Iinclude -I./arch/arm64/include/uapi -Iarch/arm64/include/generated/uapi -I./include/uapi -Iinclude/generated/uapi -include ./include/linux/kconfig.h -D__KERNEL__ -mlittle-endian -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -std=gnu89 -fno-PIE -mgeneral-regs-only -DCONFIG_AS_LSE=1 -fno-pic -mpc-relative-literal-loads -fno-asynchronous-unwind-tables -fno-delete-null-pointer-checks -Wno-maybe-uninitialized -Wno-frame-address -Wno-format-truncation -Wno-format-overflow -Wno-int-in-bool-context -Wno-attribute-alias -Os --param=allow-store-data-races=0 -DCC_HAVE_ASM_GOTO -Wframe-larger-than=2048 -fno-stack-protector -Wno-unused-but-set-variable -Wno-unused-const-variable -fno-omit-frame-pointer -fno-optimize-sibling-calls -fno-var-tracking-assignments -pg -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fno-merge-all-constants -fmerge-constants -fno-stack-check -fconserve-stack -Werror=implicit-int -Werror=strict-prototypes -Werror=date-time -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(configs)" -D"KBUILD_MODNAME=KBUILD_STR(configs)" -c -o kernel/configs.o kernel/configs.c
using /usr/lib/gcc/aarch64-linux-gnu/
8/...
I guess this is on topic (to test an HDMI sound fix) but spoon-feeding me may be getting too irksome - I understand if it stops!
did you do "make distclean" before changing the compiler CC=?
CAUTION! Save your .config before doing distclean.
than copy the .config back
$ export CC=gcc-7
$ make oldconfig
$ make -j6 Image
I got confused, cause I do my builds on a x86-PC with CROSS_COMPILE=
The kernel-build ignores CC=
Just uninstall gcc8 or change the CC= inside the Makefile.
(10-20-2018, 01:12 AM)hunderteins Wrote: [ -> ]Just uninstall gcc8 or change the CC= inside the Makefile.
Couldn't find a suitable CC= edit in Makefile or scripts/Makefile...
So removed gcc-8 - a bit of collateral damage with build-essential and libdvd-pkg going as well but no matter. At which stage make decided there was no compiler despite gcc-7 being installed according to synaptic.
Code:
$ make -j6 bindeb-pkg
CHK include/config/kernel.release
make KBUILD_SRC=
CHK include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
HOSTCC scripts/basic/fixdep
/bin/sh: 1: gcc: not found
make[3]: *** [scripts/Makefile.host:91: scripts/basic/fixdep] Error 127
make[2]: *** [Makefile:472: scripts_basic] Error 2
make[1]: *** [scripts/package/Makefile:96: bindeb-pkg] Error 2
make: *** [Makefile:1319: bindeb-pkg] Error 2
As soon as I try install gcc, or build-essential they want gcc-8 as a dependency.
not script/Makefile CC= is in ./Makefile
you can always deinstall gcc from ubuntu and install an gcc-7 into /usr/local/ oder with CROSS_COMPILE= into your $HOME.
(10-18-2018, 02:28 PM)Bullet64 Wrote: [ -> ] No, very stable here. What's your setup?
16G MicroSD + 32G USB thumb drive + 500G USB drive for storage
OS on MicroSD
32G USB drive for /bitcoin/chainstate/ directory (symlink)
500G drive for /bitcoin/ directory
sudo apt update && sudo apt upgrade
Install required packages for compiling Bitcoin Core 0.17.0 from source and running it.
I'll try to reproduce.