aber die host-"tools" zum flashen, was aber leider dies dtc mitbaut.
Das liegt nun wieder nur daran, wie das von
@er13 mal eingebaut wurde in Freetz.
Insgesamt ist das mit dem "make tools" etwas unglücklich gelöst - bis hin zu den fehlenden Abhängigkeiten, wenn sich irgendwelche Quelltext-Pakete für diese Tools geändert haben und man eigentlich nicht "von vorne" bauen will. Zumindest in meinen Augen - aber hinterher ist man auch immer klüger, das will ich hier gar nicht unterschlagen/vergessen, wobei das "yourfritz-akc-host" da auch ausdrücklich ausgenommen sei, weil ich das von Beginn an anders gehandhabt hätte, denn da waren die entstehenden "Probleme" schon deutlich genug zu erkennen.
Weil mir das auch auf die Ketten ging, daß ich immer die kompletten Tools (inkl. irgendeiner BusyBox, die kein Mensch wirklich braucht) bauen sollte, wenn ich nur die beiden Programme aus den "squashfs-tools" brauchte, habe ich das letztens dann endlich mal umgestellt und etwas vereinfacht, so daß es besser (für meine Zwecke zumindest) paßt:
https://github.com/PeterPawn/YourFreetz/tree/host-tools
==============================================================================
Wenn Dich hier das Bauen von "yourfritz-akc-host" stört, lasse doch im zugehörigen Makefile (
https://github.com/Freetz-NG/freetz-ng/blob/master/tools/make/yourfritz-akc-host/src/Makefile) die "$BINS" als Ziel weg bzw. ersetze sie einfach durch passende Shell-Skripte (die brauchen ja nichts weiter als ein "echo" und/oder passende Dummy-Files ausgeben), anstatt sie durch den Compiler erzeugen zu lassen - am besten noch in Abhängigkeit davon, ob da REPLACE_KERNEL gesetzt ist oder nicht.
Ist es das nicht, wird das ganze Zeug gar nicht gebraucht - und keiner merkt, daß die Shell-Skripte nur "Dummies" sind. Voraussetzung wäre natürlich auch, daß man den Teil in "make/linux/kernel.mk", der die damit zusammenhängenden Ziele auf Kernel > 3.10 (oder so ähnlich) reduziert, auch noch von "REPLACE_KERNEL" abhängig macht - ohne diese Einstellung braucht's diese Ziele auch nicht und ohne diese Ziele, wird das "extract" und/oder das "bin2asm" gar nicht erst aufgerufen.
So würde ich das zumindest als Erstes mal versuchen - ggf. muß man noch den Patch für das Kernel-Makefile anpassen (entsprechende Bedingungen ergänzen) bzw. auch einfach weglassen (
https://github.com/Freetz-NG/freetz...3.10.73/170-avm_kernel_config.PeterPawn.patch) oder das ASM-File als Dummy ohne echten Inhalt erzeugen, so daß das aber doch gelinkt werden kann, falls aus irgendwelchen kruden Gründen das Target "$(obj)/vmlinux.lds" zum Build auserkoren wird.
Ist REPLACE_KERNEL tatsächlich gesetzt, kann/muß man halt ohnehin die richtigen Binaries bauen - das kann man aber sogar so machen, daß an die Stelle von "bin2asm" und "extract" (jeweils mit dem Präfix) zunächst mal auch nur ein Shell-Skript gesetzt wird, das aber keinen Fehlercode zurückgibt und auch keine Dummy-Files erstellt, sondern anhand der Freetz-Variablen erst mal entscheidet, ob die "richtigen" Versionen gebraucht werden und diese dann (quasi erst "bei Bedarf" - siehe der Thread zum "avm_kernel_config" irgendwo hier im IPPF) über den passenden Aufruf von "make" erstellen läßt - letztlich so ähnlich, wie sich "libtool" als Wrapper für den Linker verhält. Da spielt es dann - wenn man sie erst mal gebaut hat, weil man es mußte - auch keine Rolle mehr, wenn diese Binaries die als Wrapper genutzten Shell-Skripte von diesem Zeitpunkt an komplett ersetzen.
Ist aber alles "untested" und damit nur diverse Ideen/Optionen, wie man auf den Build dieser Teile verzichten kann, ohne das komplett über den Haufen zu werfen, was da bisher existiert. Diese Gedanken habe ich mir auch schon ein paar Mal gemacht - es hat mich bisher nur nicht dazu gebracht (einfach weil ich so selten solche Builds machen muß), das auch für meinen Fork entsprechend anzupassen - letztlich brauche ich für den Build meiner Binaries eigentlich gar keinen eigenen Kernel und das könnte (auch für meinen speziellen "use case") alles wieder raus.
