[Info] Arch Linux fehlende types.h für nfs-utils in freetz

[jocale]

Ich bin auf Arch Linux umgestiegen und hier hatte ich Probleme beim Erstellen eines Freetzimages für meine 7590, das größte Problem war das Paket nfs-utils wegen einer fehlenden Datei und möchte hier für andere meine gefunde Lösung weitergeben.

rpc/types.h

Diese befindet sich einmal im Paket libtirpc im Ordner "/usr/include/libtirpc /rpc" , aber freetz sucht im Ordner "/usr/include/rpc".
Ein Link von /usr/include/libtirpc/rpc/types.h nach "/usr/include/rpc" verursacht weitere Fehler.

Die Lösung ist folgendes Paket

#Das Paket ist eigentlich für Arm CPUs gedacht und im Paket glibc fehlt die Datei types.h 
sudo pacman -Sy aarch64-linux-gnu-glibc
# dann müssen noch einige Dateien an die richtige Stelle verlinkt
# werden damit freetz sie findet
sudo ln - s /usr/aarch64-linux-gnu/usr/include/rpc/auth.h /usr/include/rpc
sudo ln - s /usr/aarch64-linux-gnu/usr/include/rpc/auth_des.h  /usr/include/rpc
sudo ln - s /usr/aarch64-linux-gnu/usr/include/rpc/auth_unix.h  /usr/include/rpc
sudo ln - s /usr/aarch64-linux-gnu/usr/include/rpc/clnt.h  /usr/include/rpc
sudo ln - s /usr/aarch64-linux-gnu/usr/include/rpc/key_prot.h   /usr/include/rpc
sudo ln - s /usr/aarch64-linux-gnu/usr/include/rpc/netdb.h  /usr/include/rpc
sudo ln - s /usr/aarch64-linux-gnu/usr/include/rpc/pmap_clnt.h  /usr/include/rpc
sudo ln - s /usr/aarch64-linux-gnu/usr/include/rpc/pmap_prot.h  /usr/include/rpc
sudo ln - s /usr/aarch64-linux-gnu/usr/include/rpc/pmap_rmt.h  /usr/include/rpc
sudo ln - s /usr/aarch64-linux-gnu/usr/include/rpc/rpc.h  /usr/include/rpc
sudo ln - s /usr/aarch64-linux-gnu/usr/include/rpc/rpc_msg.h  /usr/include/rpc
sudo ln - s /usr/aarch64-linux-gnu/usr/include/rpc/svc.h  /usr/include/rpc
sudo ln - s /usr/aarch64-linux-gnu/usr/include/rpc/svc_auth.h  /usr/include/rpc
sudo ln - s /usr/aarch64-linux-gnu/usr/include/rpc/types.h  /usr/include/rpc
sudo ln - s /usr/aarch64-linux-gnu/usr/include/rpc/xdr.h /usr/include/rpc

Danach läuft freetz ohne Fehler durch und das Image wird erstellt, für alle die das noch interessiert, ich habe folgende Pakete für freetz installiert :

sudo pacman -S --needed yay autoconf automake binutils bison bzip2 coreutils eclipse-ecj fastjar flex gawk gcc gettext git glibc graphicsmagick libtool libusb make ncurses patch patchutils perl perl-string-crc32 pkg-config python python2 ruby svn texinfo usbutils xz zlib lib32-libnsl  libwrap  lib32-libwrap libgssglue
 yay -S tofrodos

 

[PeterPawn]

Ohne das jetzt im Detail zu verstehen, was hier das Problem gewesen sein könnte ... generell sollte man wissen, daß beim Cross-Kompilieren eigentlich die Include-Files der jeweiligen Zielplattform verwendet werden müssen. Daher sollte es (bei korrekt konfigurierten Paketen) gar keine Rolle spielen, auf welcher Plattform man seine Freetz-Images erstellt.

Allerdings ist "Freetz" eben nicht nur das Erstellen der Pakete und das Zusammenstellen eines Firmware-Images ... der allererste Schritt, der bei vielen nur dank einer von Freetz zum Download zur Verfügung gestellten Datei (in großen Teilen) übersprungen wird, ist das Erstellen der notwendigen Werkzeuge (aka Toolchain), mit denen das Freetz-Image am Ende erstellt werden kann. Das ist dann auch die Stelle, wo selbst bei korrekt konfigurierten Target-Packages der Build-Host eine Rolle spielt ... denn die "Werkzeuge" werden eben auf dieser Plattform ausgeführt und müssen damit auch dazu passen.

Wer also Probleme mit der Toolchain hat, sollte als ersten Schritt das Erstellen einer eigenen Toolchain in Erwägung ziehen (wenn er nicht gerade auf den "üblichen" Systemen von Canonical - aka Ubuntu und Ableger - arbeitet) und muß dazu nur eine Einstellung in "make menuconfig" umstellen: "Build own toolchains (requires 4GB diskspace)" ... diese ist allerdings nur dann sichtbar, wenn man das eigene Level der Vorkenntnisse auf "Experte" umgestellt hat. Letztere Einstellung steht ziemlich am Beginn des Hauptmenüs (als "user competence") und die Toolchain-Einstellungen findet man dann unten bei "build system".

Danach braucht es ggf. etwas mehr Zeit, den ersten Durchlauf zu beenden (weil jetzt sowohl der C-Compiler - in der richtigen Version - als auch die C-Library für das Zielsystem - ebenfalls in der richtigen Version - erst einmal erstellt werden müssen) ... das ist aber der Preis, den man zahlen muß, wenn man auf ein System für den Build-Host setzt, das nicht mit dem übereinstimmt, für welches die zum Download angebotenen Toolchains erstellt wurden.

-------------------------------------------------------------------------------------------

Wenn danach noch Probleme beim Kompilieren von Paketen auftauchen, dann muß man weitersehen ... aber wenn ein Target-Package tatsächlich auf die Header-Dateien im Build-Host zurückgreift, ist das (per se) erst einmal "unerwünscht". Es kann nämlich niemand garantieren, daß diese Dateien für das Target-System und für den Build-Host identisch sind ... das hängt von sehr vielen Faktoren ab und unterschiedliche Kernelversionen für Build-Host und Target sind schon mal denkbar schlechte Voraussetzungen.

Da hier aber alle wichtigen Infos fehlen (u.a. der genaue Fehler und das dabei behandelte Freetz-Paket), kann man nichts Genaueres zur Ursache des Fehlers sagen ... ja, nicht einmal ohne Zweifel klären, ob es um die Toolchain ging (wobei dabei NFS eigentlich keine Rolle spielen sollte) oder wirklich um ein Paket für das Zielsystem. Letzteres sollte keinesfalls auf eine Header-Datei des Host-Systems angewiesen sein ... alle für die Pakete notwendigen Header-Files (hinsichtlich des Kernels und der C-Library) sollten von der Toolchain passend eingerichtet werden, bevor sie sich an das Kompilieren von Paketen für das Zielsystem macht.

Man kann also mit solchen "Patch-Versuchen" wie in #1 vielleicht auch Erfolge erzielen ... aber das ist eher nicht zu empfehlen. Die in #1 als fehlend angegebene Header-Datei "rcp/types.h" gehört z.B. zur C-Library und sollte bei einer (korrekt gebauten) Toolchain unter dem Pfad "toolchain/build/mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/mips-linux-uclibc/include/rpc/types.h" zu finden sein ... und zwar in der passenden Version für die "Komponenten", die sich aus dem Pfadnamen ablesen lassen - also für MIPS-Plattform, den C-Compiler (gcc 5.5.0) und die C-Library für die Zielplattform (uClibc-ng 1.0.14). Das dürfte sogar für die 7590 und die 7490 (aus deren Toolchain stammt meine Pfadangabe oben) identisch sein.

 

[jocale]

Erstmal vielen Dank für deine Erklärung, wieder was dazu gelernt.
Hier die Fehlermeldung bevor die Maßnahmen aus #1 durchgeführt habe und den Menüpunkt den du ansprichst war bereits aktiviert.

2.3/tools/rpcgen“ wird betreten gcc -DHAVE_CONFIG_H -I. -I../../support/include -D_GNU_SOURCE -MT rpcgen-rpc_clntout.o -MD -MP -MF .deps/rpcgen-rpc_clntout.Tpo -c -o rpcgen-rpc_clntout.o `test -f 'rpc_clntout.c' || echo './'`rpc_clntout.c gcc -DHAVE_CONFIG_H -I. -I../../support/include -D_GNU_SOURCE -MT rpcgen-rpc_cout.o -MD -MP -MF .deps/rpcgen-rpc_cout.Tpo -c -o rpcgen-rpc_cout.o `test -f 'rpc_cout.c' || echo './'`rpc_cout.c gcc -DHAVE_CONFIG_H -I. -I../../support/include -D_GNU_SOURCE -MT rpcgen-rpc_hout.o -MD -MP -MF .deps/rpcgen-rpc_hout.Tpo -c -o rpcgen-rpc_hout.o `test -f 'rpc_hout.c' || echo './'`rpc_hout.c gcc -DHAVE_CONFIG_H -I. -I../../support/include -D_GNU_SOURCE -MT rpcgen-rpc_main.o -MD -MP -MF .deps/rpcgen-rpc_main.Tpo -c -o rpcgen-rpc_main.o `test -f 'rpc_main.c' || echo './'`rpc_main.c rpc_clntout.c:39:10: schwerwiegender Fehler: rpc/types.h: Datei oder Verzeichnis nicht gefunden #include <rpc/types.h> ^~~~~~~~~~~~~ Kompilierung beendet. make[3]: *** [Makefile:352: rpcgen-rpc_clntout.o] Fehler 1 make[3]: *** Es wird auf noch nicht beendete Prozesse gewartet.... mv -f .deps/rpcgen-rpc_hout.Tpo .deps/rpcgen-rpc_hout.Po mv -f .deps/rpcgen-rpc_cout.Tpo .deps/rpcgen-rpc_cout.Po mv -f .deps/rpcgen-rpc_main.Tpo .deps/rpcgen-rpc_main.Po make[3]: Verzeichnis „/media/lager/downloads/.Werkstatt/Freetz/freetz0901/source/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/nfs-utils-1.2.3/tools/rpcgen“ wird verlassen make[2]: *** [Makefile:318: all-recursive] Fehler 1 make[2]: Verzeichnis „/media/lager/downloads/.Werkstatt/Freetz/freetz0901/source/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/nfs-utils-1.2.3/tools“ wird verlassen make[1]: *** [Makefile:380: all-recursive] Fehler 1 make[1]: Verzeichnis „/media/lager/downloads/.Werkstatt/Freetz/freetz0901/source/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/nfs-utils-1.2.3“ wird verlassen ERROR: Build failed. make: *** [make/nfs-utils/nfs-utils.mk:37: source/target-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/nfs-utils-1.2.3/utils/exportfs/exportfs] Fehler 1 make 13223,29s user 1449,50s system 243% cpu 1:40:17,07 total

Ich habe in der virtuellen Maschine Kubuntu installiert und dort läuft alles ohne Fehler und auch das übertragen des Images läuft auch ohne Probleme, das mit Arch Linux ist mehr sportlich Ehrgeiz und ich einfach ausprobieren ob freetz auch dort fehlerfrei läuft.

 

[PeterPawn]

Schon die Tatsache, daß da "gcc" anstelle von etwas wie "mips-unknown-linux-gnu-gcc" aufgerufen wird, zeigt für mich, daß hier nicht wirklich ein "cross compile" stattfindet - es wäre jedenfalls für mich sehr überraschend, wenn sich hinter dem ersten Auftreten von "gcc" im Pfad bei dieser Arch Linux-Installation der GNU C-Compiler verbergen sollte, der am Ende MIPS-Code ausgibt (ich nehme mal an, daß der Build-Host auf x86 oder x64 läuft). Auch die Include-Pfade (die Parameter "-I" - großes i - beim Aufruf des "gcc") passen so gar nicht zum "cross compile" - da stimmt wohl was mit der automatischen Konfiguration der Übersetzung von "rpcgen" durch "autoconf/configure" nicht, wenn das Ergebnis kein Makefile für die korrekte Übersetzung für das Zielsystem ist.

Ich kann mir aber auch nicht wirklich vorstellen, daß dieser Fehler dann durch die in #1 beschriebenen Schritte behoben wurde und damit durch den "gcc"-Aufruf am Ende Code erzeugt wurde, der im generierten Freetz-Image tatsächlich irgendetwas zu suchen hatte.

Auch zeigt der Blick in das Paket-Makefile (https://github.com/Freetz/freetz/blob/master/make/nfs-utils/nfs-utils.mk#L6), daß "rpcgen" zumindest mal kein "primäres Ziel" der Übersetzung für die Zielplattform ist - bleibt die Frage, warum das hier überhaupt gebaut wird.

Mögliche Erklärungen wären vorhandene Abhängigkeiten bei den vier "erwünschten" Binärdateien (aber auch dann macht es wenig Sinn, die Quellen mit dem Host-Compiler zu übersetzen) oder zwischenzeitliche Änderungen im "nfs-util"-Paket, das dann nur durch eine neuere Version ersetzt wurde, ohne die ausgeführten Schritte beim "make" noch einmal zu analysieren.

In dem Zusammenhang wäre es halt mal interessant, ob das Paket (bzw. konkret das "rpcgen") auf einem Ubuntu-Abkömmling tatsächlich für das Zielsystem übersetzt wird (da also der Cross-Compiler zum Einsatz kommt) oder ob auch dort - wie es bei mir unter openSuSE Tumbleweed auch der Fall ist, ebenso wie bei Dir unter Arch Linux - versucht wird, für den Host zu übersetzen.

Fazit: Da gibt es ein Problem im Paket "nfs-util" selbst ... Dein Build-System ist daran vermutlich ebenso unschuldig, wie meines unter Tumbleweed. Mal sehen, ob ich Zeit zum Drüberschauen finde - aber vielleicht ist das bis dahin auch alles bereits von jemand anderem (vielleicht ja @er13?) geregelt. Wenn ich das (für mich) "von Hand" machen müßte, würde ich zunächst mal "rpcgen" als Build-Target ausschließen durch passendes Patchen der originalen Dateien - ich denke mal nicht, daß es tatsächlich gebraucht wird und dann muß es auch nicht übersetzt werden. Schon wäre das Problem behoben ... sofern nicht weitere Binaries aus dem "nfs-util"-Paket dann noch ähnliche Probleme bereiten.

Weil das vielleicht nicht allen potentiellen Freetz-Benutzern klar ist ... das gesamte "nfs-util"-Paket wird eigentlich nur dann benötigt, wenn die FRITZ!Box selbst als NFS-Server verwendet werden soll - für den Client reichen die Möglichkeiten in der BusyBox (inkl. des Mountens von NFS-Exports anderer Systeme) eigentlich aus.

 

[olistudent]

Ich meine mich zu erinnern ( ), dass rpc tatsächlich mit dem Host-Compiler kompiliert wird und in den weiteren Schritten irgendwas erzeugt!?

Hier fehlt also vermutlich die Header-Datei wirklich im Hostsystem...

Gruß,
Oliver

 

[jocale]

@PeterPawn, danke für deine Ausführungen.
Mir geht's unter Arch, wie bereits erwähnt, mehr um zu testen ob es hier auch geht.

Da ich aber seit kurzem eine SSD im Laptop habe, läuft Kubuntu in Virtualbox sehr zackig, daher belasse ich erstmal dabei.



Gesendet von meinem GT-N5110 mit Tapatalk