Freetz-NG Compile Error (Cannot use CONFIG_CC_STACKPROTECTOR_REGULAR: -fstack-protector not supported by compiler)

[berndy2001]

Wollte mal freetz-ng anschauen, klappt aber nicht. Suche ergab nichts.

user@hs:~/freetz-ng$ make
WARNING: The program inkscape was not found in path.
cmd() { PATH="/home/user/freetz-ng/toolchain/build/mips_gcc-5.5.0_uClibc-1.0.15-nptl_kernel-4.9/mips-linux-uclibc/bin:/home/user/freetz-ng/toolchain/build/mips_gcc-5.5.0/mips-unknown-linux-gnu/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" LD_RUN_PATH="/usr/lib/freetz" FREETZ_LIBRARY_DIR="/usr/lib/freetz" make -j2  "$@"  || { printf "\n\\033[33m%s\\033[m\n" "ERROR: Build failed.";  exit 1; } };    if [ -e source/.echo_item_start -a ! -e source/.echo_item_build ]; then echo -ne "\e[48;5;56mbuilding\e[49m ... "; touch source/.echo_item_build; fi; cmd -C source/kernel/ref-grx5-7590_07.20/linux-4.9 CROSS_COMPILE="mips-unknown-linux-gnu-" KERNEL_MAKE_PATH="/home/user/freetz-ng/toolchain/build/mips_gcc-5.5.0/mips-unknown-linux-gnu/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" ARCH="mips" INSTALL_HDR_PATH=/home/user/freetz-ng/source/toolchain-mips_gcc-5.5.0_uClibc-1.0.15-nptl_kernel-4.9/linux-dev/4.9 INSTALL_MOD_PATH="/home/user/freetz-ng/source/kernel/ref-grx5-7590_07.20" V=1 prepare
make[1]: Verzeichnis „/home/user/freetz-ng/source/kernel/ref-grx5-7590_07.20/linux-4.9“ wird betreten
linux/GNUmakefile: including /home/user/freetz-ng/source/kernel/ref-grx5-7590_07.20/linux-4.9/.kernelvariables
make[2]: Verzeichnis „/home/user/freetz-ng/source/kernel/ref-grx5-7590_07.20/linux-4.9“ wird betreten
make -f ./scripts/Makefile.build obj=scripts/basic
set -e; : '  CHK     include/config/kernel.release'; mkdir -p include/config/;  echo "4.9.198$(/bin/bash ./scripts/setlocalversion .)" < include/config/auto.conf > include/config/kernel.release.tmp; if [ -r include/config/kernel.release ] && cmp -s include/config/kernel.release include/config/kernel.release.tmp; then rm -f include/config/kernel.release.tmp; else : '  UPD     include/config/kernel.release'; mv -f include/config/kernel.release.tmp include/config/kernel.release; fi
rm -f .tmp_quiet_recordmcount
Cannot use CONFIG_CC_STACKPROTECTOR_REGULAR: -fstack-protector not supported by compiler
make[2]: *** [Makefile:1106: prepare-compiler-check] Fehler 1
make[2]: *** Es wird auf noch nicht beendete Prozesse gewartet....
make[2]: Verzeichnis „/home/user/freetz-ng/source/kernel/ref-grx5-7590_07.20/linux-4.9“ wird verlassen
make[1]: *** [GNUmakefile:101: prepare] Fehler 2
make[1]: Verzeichnis „/home/user/freetz-ng/source/kernel/ref-grx5-7590_07.20/linux-4.9“ wird verlassen

ERROR: Build failed.
make: *** [make/linux/kernel.mk:139: source/kernel/ref-grx5-7590_07.20/.prepared] Fehler 1

Was tun? System ist ein aktuelles Debian 10 mit einem frischen Checkout. Fehlt mir ein Paket? Originales Freetz kompiliert ohne Probleme.

 

[PeterPawn]

Originales Freetz kompiliert ohne Probleme.

Aber wohl kaum für 07.20 ... ich vermute mal, wenn Du bei Freetz-NG auf 07.1x zurückstellst (und damit nicht versucht wird, die Kernel-Version 4.9 zu bauen), klappt's auch mit dem Nachbarn - und fürs "mal anschauen" sollte 07.20 jetzt nicht unbedingt benötigt werden.

BTW: Das ist auch irgendein Folgefehler (der fürs Cross-Compile verwendete "gcc" kennt eine notwendige Option nicht) - daher bringt das Stück Protokoll oben nicht wirklich Erleuchtung. Eher schon bräuchte man das gesamte Build-Protokoll (dafür gibt's ein "fmake" im Freetz-Wurzelverzeichnis) und auch die verwendete Konfigurationsdatei kann eigentlich nie schaden, am besten sogar noch die komprimierte Form, wo nur die geänderten Werte verzeichnet sind (den Rest kann man sich dann denken oder bei Bedarf selbst erstellen).

 

[berndy2001]

Aber wohl kaum für 07.20 ... ich vermute mal, wenn Du bei Freetz-NG auf 07.1x zurückstellst (und damit nicht versucht wird, die Kernel-Version 4.9 zu bauen), klappt's auch mit dem Nachbarn

Da hast du recht. Danke für den Hinweis.

und fürs "mal anschauen" sollte 07.20 jetzt nicht unbedingt benötigt werden.

Eigentlich wollte ich die 07.20 anschauen

dafür gibt's ein "fmake" im Freetz-Wurzelverzeichnis

Log anbei

und auch die verwendete Konfigurationsdatei kann eigentlich nie schaden

auch anbei.

am besten sogar noch die komprimierte Form, wo nur die geänderten Werte verzeichnet sind (den Rest kann man sich dann denken oder bei Bedarf selbst erstellen).

Ich weiß was du meinst, aber die compressed habe ich nicht. Die wird ja, so weit ich weiß, erst später erstellt.

Danke für deine Hilfe

 

[PeterPawn]

Eigentlich wollte ich die 07.20 anschauen

Das ist dann ja schlecht.

Da wirst Du wohl warten müssen, bis das Bauen des Kernels 4.9 repariert wurde ... mir fehlt im Moment leider die Zeit, um mir das richtig anzusehen. und helfen könnte ich Dir ohnehin nur mit Hinweisen für eigene Patches.

Angesichts des letzten Commits in Freetz-NG: https://github.com/Freetz-NG/freetz-ng/commit/23b5254fcec2f99598ee289581280202cc72153a und des dazugehörigen Kommentars " fix kernel 4.9.198" fehlt mir sogar die Phantasie, ob dieser Commit nun den Fehler beheben sollte oder ob er ihn erst hinzugefügt bzw. sichtbar gemacht hat. Das ist halt die Krux, wenn die Kommentare im Commit so "vielsagend" sind.

Angesichts der Tatsache, daß da jetzt "CONFIG_CC_STACKPROTECTOR" aktiviert wird (so um Zeile 430 in der entsprechenden Kernel-Config herum), würde ich am ehesten darauf tippen, daß dieser Commit (ca. 5 h alt) bei Dir schon drin ist und nun halt noch die Patches zum Erzeugen eines passenden GCC fehlen - aber das ist nur geraten anhand der Symptome und des Timings der Commits.

@opto/cuma/fda77:
Das ist z.B. einer der Kritikpunkte, von denen ich (Du weißt wo) geschrieben habe ... die Benutzer des Forks haben gar keine richtige Chance zu erkennen, daß/ob die Unterstützung für 07.20 nun funktioniert oder nicht, wenn Du das alles in den Haupt-Branch packst, anstatt das erst mal in einem passenden Feature-Branch so weit vorzubereiten, bis man das (nach entsprechendem Test, dazu gehört dann halt auch das Bauen des Kernels, wenn's eingebaut wurde) dann in einem Rutsch übernehmen kann.

So werden immer auch die Freetz-User (ob sie das wollen oder nicht und manch anderer würde vermutlich auch dem NG-Fork folgen, wenn halbwegs sicher wäre, daß der auch funktioniert - und zwar dann, wenn er es braucht ... die (schon gehäuften) Probleme sind nun mal die Kehrseite der vielen Änderungen, die Du da vornimmst) zu "Versuchskaninchen" gemacht - wenn das "freiwillig" ist/wäre, ist das etwas anderes.

Ich weiß, daß das halt die "Arbeitsweise" bei Freetz generell ist (etwas abgemildert mittlerweile beim Freetz/freetz, weil die Commits/PRs nur nach langer Zeit ihren Weg in den "master"-Branch finden, wenn überhaupt) - aber das macht es ja nicht unbedingt "alternativlos" und letzten Endes sind diese VCS ja irgendwo genau für diese Zwecke auch entwickelt worden (ansonsten reicht ja auch eine einfache Verzeichnisstruktur mit der "letzten Version", die dann jeder kopieren kann), damit man da verschiedene Versionen "ausprobieren" und bereitstellen kann. Da ist es schon "komisch", wenn das immer nur eine einzige ist - ob die nun "Trunk" genannt wird, wie unter SVN, oder "master" wie bei Git. Das Prinzip ist dasselbe ... Fehler finden ungefiltert ihren Weg zu denen, die das eigentlich nur "verwenden" wollen.

 

[berndy2001]

Angesichts des letzten Commits in Freetz-NG: https://github.com/Freetz-NG/freetz-ng/commit/23b5254fcec2f99598ee289581280202cc72153a und des dazugehörigen Kommentars " fix kernel 4.9.198" fehlt mir sogar die Phantasie, ob dieser Commit nun den Fehler beheben sollte oder ob er ihn erst hinzugefügt bzw. sichtbar gemacht hat. Das ist halt die Krux, wenn die Kommentare im Commit so "vielsagend" sind.

Ich habe jetzt mal testweise auf den Commit davor gewechselt und nachdem ich weiters 'bc' als neue Abhängigkeit installiert habe, lief es nun durch.

die Benutzer des Forks haben gar keine richtige Chance zu erkennen, daß/ob die Unterstützung für 07.20 nun funktioniert oder nicht, wenn Du das alles in den Haupt-Branch packst, anstatt das erst mal in einem passenden Feature-Branch so weit vorzubereiten, bis man das (nach entsprechendem Test, dazu gehört dann halt auch das Bauen des Kernels, wenn's eingebaut wurde) dann in einem Rutsch übernehmen kann.

Würde ich auch befürworten. Auch ein experimental-Hinweis wie in freetz wäre sicherlich nicht verkehrt.

 

[PeterPawn]

nachdem ich weiters 'bc' als neue Abhängigkeit installiert habe

Ja, das ist schon länger eine Voraussetzung (https://github.com/PeterPawn/YourFreetz/commit/265316242efd5d27440ec9e03997fe7ddff94ecf war mein letzter "rebase"-Lauf) ... vielleicht baut es ja mal jemand in die ".build-prerequisites" ein (@er13 und @opto seien hier mal "erwähnt", damit sie die Benachrichtigungen dazu erhalten). Allerdings wird es nur benötigt, wenn man tatsächlich den eigenen Kernel bauen (lassen) möchte - deshalb habe ich es (bei mir) als "weak" eingetragen.

EDIT:
Wobei ich vorhin auch noch mal nach dem GCC für GRX-Boxen gesehen hatte (Freetz-Toolchain auf einem RasPi 4 selbst erzeugt, allerdings mit meinem Fork, der aber an der Stelle nichts wirklich ändert) und da kann ich die Annahme oben in #1, daß der verwendete GCC kein "-fstack-protector" kennt, nicht nachvollziehen:

pi@pi4:/media/pi/extern_10_320/pi4/builds/grx5 $ toolchain/build/mips_gcc-5.5.0/mips-unknown-linux-gnu/bin/mips-unknown-linux-gnu-gcc --version
mips-unknown-linux-gnu-gcc (GCC) 5.5.0
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.

pi@pi4:/media/pi/extern_10_320/pi4/builds/grx5 $ printf "void main();" > ../../work/test.c
pi@pi4:/media/pi/extern_10_320/pi4/builds/grx5 $ toolchain/build/mips_gcc-5.5.0/mips-unknown-linux-gnu/bin/mips-unknown-linux-gnu-gcc -fstack-protector ../../work/test.c
/media/pi/extern_10_320/pi4/builds/grx5/toolchain/build/mips_gcc-5.5.0/mips-unknown-linux-gnu/lib/gcc/mips-unknown-linux-gnu/5.5.0/../../../../mips-unknown-linux-gnu/bin/ld: cannot find crt1.o: No such file or directory
/media/pi/extern_10_320/pi4/builds/grx5/toolchain/build/mips_gcc-5.5.0/mips-unknown-linux-gnu/lib/gcc/mips-unknown-linux-gnu/5.5.0/../../../../mips-unknown-linux-gnu/bin/ld: cannot find crti.o: No such file or directory
/media/pi/extern_10_320/pi4/builds/grx5/toolchain/build/mips_gcc-5.5.0/mips-unknown-linux-gnu/lib/gcc/mips-unknown-linux-gnu/5.5.0/../../../../mips-unknown-linux-gnu/bin/ld: cannot find crtbegin.o: No such file or directory
/media/pi/extern_10_320/pi4/builds/grx5/toolchain/build/mips_gcc-5.5.0/mips-unknown-linux-gnu/lib/gcc/mips-unknown-linux-gnu/5.5.0/../../../../mips-unknown-linux-gnu/bin/ld: cannot find -lssp_nonshared
/media/pi/extern_10_320/pi4/builds/grx5/toolchain/build/mips_gcc-5.5.0/mips-unknown-linux-gnu/lib/gcc/mips-unknown-linux-gnu/5.5.0/../../../../mips-unknown-linux-gnu/bin/ld: cannot find -lssp
/media/pi/extern_10_320/pi4/builds/grx5/toolchain/build/mips_gcc-5.5.0/mips-unknown-linux-gnu/lib/gcc/mips-unknown-linux-gnu/5.5.0/../../../../mips-unknown-linux-gnu/bin/ld: cannot find -lgcc
/media/pi/extern_10_320/pi4/builds/grx5/toolchain/build/mips_gcc-5.5.0/mips-unknown-linux-gnu/lib/gcc/mips-unknown-linux-gnu/5.5.0/../../../../mips-unknown-linux-gnu/bin/ld: cannot find -lc
/media/pi/extern_10_320/pi4/builds/grx5/toolchain/build/mips_gcc-5.5.0/mips-unknown-linux-gnu/lib/gcc/mips-unknown-linux-gnu/5.5.0/../../../../mips-unknown-linux-gnu/bin/ld: cannot find -lgcc
/media/pi/extern_10_320/pi4/builds/grx5/toolchain/build/mips_gcc-5.5.0/mips-unknown-linux-gnu/lib/gcc/mips-unknown-linux-gnu/5.5.0/../../../../mips-unknown-linux-gnu/bin/ld: cannot find crtend.o: No such file or directory
/media/pi/extern_10_320/pi4/builds/grx5/toolchain/build/mips_gcc-5.5.0/mips-unknown-linux-gnu/lib/gcc/mips-unknown-linux-gnu/5.5.0/../../../../mips-unknown-linux-gnu/bin/ld: cannot find crtn.o: No such file or directory
collect2: error: ld returned 1 exit status
pi@pi4:/media/pi/extern_10_320/pi4/builds/grx5 $ gcc ../../work/test.c
/usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabihf/8/../../../arm-linux-gnueabihf/crt1.o: in function `_start':
(.text+0x34): undefined reference to `main'
collect2: error: ld returned 1 exit status
pi@pi4:/media/pi/extern_10_320/pi4/builds/grx5 $

Der GCC scheitert also jeweils an fehlenden Libraries und nicht an der unbekannten Option -fstack-protector, auch wenn Freetz i.d.R. alles mit -fno-stack-protector übersetzt.

Es liegt wohl eher am "make" für den Kernel, wo bei der Auswertung von "CONFIG_CC_STACKPROTECTOR_REGULAR" irgendetwas schief geht.

 

[berndy2001]

Opto hat mich auf die Newsseite hingewiesen, wo der branch kernel49 erwähnt wird. Da dessen Funktionalität aber unbekannt ist, sehe ich von einem Test ab.