[Frage] Bitte um jq-Binary

[Chatty]

Hallo,

wäre jemand so nett mit einer bestehenden cross compile toolchain ein jq-Binary für die 7490 zu erstellen? "jq is written in portable C, and it has zero runtime dependencies." Ich benötige es, um etwas JSON zu parsen.

Kleine Nebenfrage: Warum funktionieren die mips-Binaries von Debian nicht? Scheint von der Properties auch ein 32bit big endian mips shared library zu sein?!

EDIT: Nachdem die Resonanz bisher ausgesprochen zurückhaltend war, habe ich unter Fedora 27 hoffentlich alle Dependencies installiert und den aktuellen Freetz-Trunk (R14597) ausgecheckt und make menuconfig und make toolchain probiert. Leider bricht letzteres mit folgendem Fehler ab:

mkdir -p .tmp_versions
make -f scripts/Makefile.build obj=.
mkdir -p kernel/
  mips-unknown-linux-gnu-gcc -Wp,-MD,kernel/.bounds.s.d  -nostdinc -isystem  -I/home/osboxes/freetz-devel/source/kernel/ref-vr9-7490_06.92/linux-3.10/arch/mips/include -Iarch/mips/include/generated  -Iinclude -I/home/osboxes/freetz-devel/source/kernel/ref-vr9-7490_06.92/linux-3.10/arch/mips/include/uapi -Iarch/mips/include/generated/uapi -I/home/osboxes/freetz-devel/source/kernel/ref-vr9-7490_06.92/linux-3.10/include/uapi -Iinclude/generated/uapi -include /home/osboxes/freetz-devel/source/kernel/ref-vr9-7490_06.92/linux-3.10/include/linux/kconfig.h -D__KERNEL__ -DVMLINUX_LOAD_ADDRESS=0xffffffff80002000 -DDATAOFFSET=0 -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -O2 -fno-reorder-blocks -fno-tree-ch -freorder-blocks-and-partition -ffunction-sections -falign-functions=32 -falign-loops=32 -falign-jumps=32 -fstrict-volatile-bitfields -mabi=32 -G 0 -mno-abicalls -fno-pic -pipe -msoft-float -ffreestanding -Wa,-march=34kc -Wa,--trap -I/home/osboxes/freetz-devel/source/kernel/ref-vr9-7490_06.92/linux-3.10/arch/mips/include/asm/mach-lantiq -I/home/osboxes/freetz-devel/source/kernel/ref-vr9-7490_06.92/linux-3.10/arch/mips/include/asm/mach-lantiq/common -I/home/osboxes/freetz-devel/source/kernel/ref-vr9-7490_06.92/linux-3.10/arch/mips/include/asm/mach-lantiq/vr9 -I/home/osboxes/freetz-devel/source/kernel/ref-vr9-7490_06.92/linux-3.10/arch/mips/lantiq/common -I/home/osboxes/freetz-devel/source/kernel/ref-vr9-7490_06.92/linux-3.10/arch/mips/lantiq/vr9 -I/home/osboxes/freetz-devel/source/kernel/ref-vr9-7490_06.92/linux-3.10/arch/mips/include/asm/mach-lantiq/xway -I/home/osboxes/freetz-devel/source/kernel/ref-vr9-7490_06.92/linux-3.10/arch/mips/include/asm/mach-generic -fomit-frame-pointer -g    -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(bounds)"  -D"KBUILD_MODNAME=KBUILD_STR(bounds)" -fverbose-asm -S -o kernel/bounds.s kernel/bounds.c
/bin/sh: /home/osboxes/freetz-devel/toolchain/build/mips_gcc-4.8.5/mips-unknown-linux-gnu/bin/mips-unknown-linux-gnu-gcc: No such file or directory
make[2]: *** [/home/osboxes/freetz-devel/source/kernel/ref-vr9-7490_06.92/linux-3.10/./Kbuild:36: kernel/bounds.s] Fehler 127
make[1]: *** [Makefile:844: prepare0] Fehler 2
make[1]: Verzeichnis „/home/osboxes/freetz-devel/source/kernel/ref-vr9-7490_06.92/linux-3.10“ wird verlassen

ERROR: Build failed.
make: *** [make/linux/kernel.mk:148: source/kernel/ref-vr9-7490_06.92/.prepared] Fehler 1

 

[rolex0815]

Hier wäre ein Package:

file ../mips/jq-1.5-mips/bin/jq
../mips/jq-1.5-mips/bin/jq: ELF 32-bit MSB executable, MIPS, MIPS32 rel2 version 1 (SYSV), statically linked, with debug_info, not stripped

 

[Chatty]

Danke @rolex0815 - funktioniert so weit. Dann mal an die Arbeit...

 

[PeterPawn]

"make toolchain" (als "build target" - https://github.com/Freetz/freetz/blob/master/Makefile#L326) ist eigentlich dafür gedacht, aus der bereits erstellten/getesteten Toolchain (die bei "make" mit "eigene Toolchain bauen" in den Menü-Einstellungen auch automatisch erzeugt wird und ansonsten für die "normale Freetz-Verwendung" ohnehin schon vorbereitet/vorkompiliert ist - wenn auch nur mit 24kc-Support, obwohl auch AVM 34kc verwendet - und nur noch von einem Support-Server für Freetz geladen wird) die Datei zu erzeugen, die man für eben diesen, vorstehend genannten Download brauchen würde. Zwar ist da wg. der Abhängigkeiten vermutlich auch ein kompletter Build der Toolchain machbar über dieses Target, aber - wie gesagt - man muß die eigentlich nur in seltenen Fällen selbst erzeugen, wenn man abweichende Einstellungen zum Freetz-Trunk verwenden will (wie ich es z.B. mit der Optimierung für "34kc" mache).

Damit hat der "normale Nutzer" mit "make toolchain" praktisch nie etwas zu tun - was bei Dir da jetzt konkret schiefläuft, ist aus dem Schnipsel nur schwer zu ersehen.

Ansonsten sind die Debian-Pakete halt gegen eine "glibc" gelinkt und da gibt es nicht überall 1:1-Mappings in den Funktionen der C-Libraries, denn die FRITZ!Box verwendet bekanntlich die uClibc, die eher für "embedded devices" geeignet ist, auch wenn die echten Platzprobleme im Flash inzwischen der Vergangenheit angehören.

Es ist auch nicht ganz trivial, eine jq-Version mit der Freetz-Toolchain zu erstellen ... erstens fehlt die "libonig.so" (also "Oniguruma" - eine neuere Bibliothek für REs, die z.B. inzwischen auch von Ruby verwendet wird und ohne die gibt es eigentlich keinen RE-Support im "jq"-Binary) und zweitens gibt es (zumindest bei mir) auch noch Schwierigkeiten damit, daß im Config-Cache angeblich vier mathematische Funktionen (Bessel - j0, j1, y0, y1) vorhanden sind, die aber (auch wieder nur bei mir, weil ich nur für meine eigene Toolchain auf Freetz-Basis da eine Aussage treffen kann und will) gar nicht beim Build der Toolchain erzeugt wurden (https://github.com/PeterPawn/freetz...clibc/configs/freetz/config-mips-0.9.33.2#L63 - wobei das beim Freetz-Original auch nicht anders sein sollte: https://github.com/Freetz/freetz/bl...clibc/configs/freetz/config-mips-0.9.33.2#L63).

Für Oniguruma habe ich mal ein Freetz-Library-Paket eingecheckt (in meinen Fork, mit dem Freetz-Trunk habe ich nichts zu tun): https://github.com/PeterPawn/freetz/commit/0604e65b3851853cc28ba4234b8643fef90f8371

Da man "jq" in Freetz dann sowohl als dynamisch als auch als statisch gelinktes Binary bauen können soll (so zumindest mein Plan), ist das eingecheckte "jq"-Paket (https://github.com/PeterPawn/freetz/commit/a90dcf1e57ef61d24cf3286cbebf0e61574b22be) auch noch nicht ganz fertig ... "jq" möchte entweder komplett statisch gelinkt werden (EDIT: bzw. linkt die "libonig" auch statisch, wenn die C-Runtime dynamisch verwendet wird) oder neben der "libonig.so" auch noch seine eigene "libjq.so" dynamisch verwendet sehen (ansonsten müßte man wieder im "automake" für das Paket herumfummeln) - damit muß das Paket noch um die Installation (ggf. wieder mit "externals"-Support, weil die auch nicht gerade ein Leichtgewicht ist) für diese "libjq.so" erweitert werden.

Es ist also nicht so, daß man (bzw. ich) Dich gar nicht wahrgenommen hätte (siehe die Zeiten bei den beiden Commits, auch wenn das "push" erst vor kurzem erfolgte) ... aber das ist eben keinesfalls (jedenfalls dann, wenn man es nicht nur als Binärdatei bereitstellen will, sondern auch den Weg dahin bereiten möchte - was für mich nun einmal dazugehört, auch wenn sowohl "jq" als auch "Oniguruma" kein Veröffentlichen von Quellen erzwingen über ihre Lizenz) mal eben "im Handstreich" erledigt (wie es in #1 irgendwie klingt).

 

[Chatty]

Ein einfaches make brachte zu Tage, dass noch die Anbhängigkeit glibc-devel.i686 erfüllt werden musste. Danach konnte ich auch make toolchain durchführen.
Deinen Branch werde ich morgen mal testen. Aber was heißt noch nicht ganz fertig? Oder: was ist schon fertig?

Meine Einschätzung aus #1 zum Aufwand hatte ich aus der dort zitierten Aussage abgeleitet, das es zumindest keine runtime Abhängigkeiten gibt und man evtl. bei vorhandener Toolchain nur den gcc anschmeißen muss. Dank @rolex0815 habe ich dieses Ergebnis ja auch schon

 

[PeterPawn]

Das jq-Binary wird zwar gebaut (erst recht, wenn man es "all static" will), aber bei der "dynamic"-Variante" (wenn parallel noch das paketeigene "--disable-static" verwendet wird, was wohl der einzige Weg ist, die "libonig.so" ebenfalls dynamisch zu nutzen - bei allen anderen Varianten wird sie bei mir immer statisch dazugelinkt, auch wenn die C-Lib dynamisch bleibt) wird die dann benötigte "libjq.so" nicht automatisch ins erzeugte Image kopiert und das ganze Paket (das Binary und die Library) sollte sich (rein aus "Höflichkeit", weil schon das Binary mit 400-800 KByte recht groß gerät und die Lib dann den anderen Teil des Speichers braucht - zumindest für frühere Verwendungsarten, wo um jedes Byte gekämpft werden mußte, ist das ziemlich viel) auch bei der Verwendung von "externals" auslagern lassen.

EDIT:
Ja, in den Aussagen auf der Homepage von "jq" kann man sogar wieder erkennen, daß dieses Linken offenbar absichtlich so erfolgt ... denn das ist es wohl, was mit "zero runtime-dependencies" gemeint ist. Aber das sind eben die Abhängigkeiten zur Laufzeit ... beim Build (zumindest für ein vollständiges Binary, man beachte den Satz zu den Builtin-Tests) wird aber noch etwas mehr benötigt (nach https://github.com/stedolan/jq/blob/master/README.md):

If you're building directly from the latest git, you'll need flex, bison (3.0 or newer), libtool, make, and autoconf installed. To get regexp support you'll also need to install Oniguruma or clone it as a git submodule as per the instructions below. (note that jq's tests require regexp support to pass).

 

[PeterPawn]

Ich habe jetzt (für mich final, solange keine Fehler zu korrigieren sind) zwei Pakete eingecheckt und sie auch als PR an den Upstream-Master gehangen ... aber es wird garantiert dauern, bis die im Trunk landen, da @er13 im Moment keine Zeit (praktisch für nichts) hat.

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

Dann kommt noch hinzu, daß der Trac-Server alles andere als stabil läuft und der Betreiber so langsam wohl auch die Lust verliert, weil man ihn einigermaßen im Regen stehen läßt mit den Entscheidungen, wie das nun mit Freetz weitergehen soll (ist aber auch etwas verquast das Ganze, denn es gibt tatsächlich nur einen Einzelnen, der im Falle eines Fehlers die Dienste bzw. den Server wieder starten kann) - wer also Wert auf das Wiki legt, sollte sich mal in nicht allzu ferner Zukunft noch spaßeshalber einen Mirror anlegen.

Mit einem beherzten:

wget -m -k -p -I wiki -I chrome http://freetz.org http://freetz.org/wikicss.css

hat man zumindest (nach etwas Zeit) mal einen Teil der Seiten auf der eigenen Festplatte und kann diese z.B. mit einem lokalen Browser über das "file"-Protokoll auch einigermaßen "durchblättern", weil die Links untereinander halbwegs funktionieren.

Für einen eigenen HTTP-Server reicht es in dieser Form allerdings noch nicht, weil die gespeicherten Seiten alle keine passenden "Content-Type"-Header haben und auch kein "Erweiterung" im Namen, über die man ihnen einen MIME-Type zuordnen könnte. Damit liefern fast alle (mir bekannten) Server diese Dateien als "application/octet-stream" aus und die Browser tendieren dazu, diese Dateien irgendwo speichern zu wollen, anstatt sie einfach anzuzeigen.

Allerdings reicht meist schon eine winzige Änderung (hier z.B. für die BusyBox und den dort enthaltenen "httpd":

diff --git a/networking/httpd.c b/networking/httpd.c
index 74196a4f1..e18e3d118 100644
--- a/networking/httpd.c
+++ b/networking/httpd.c
@@ -1683,7 +1683,7 @@ static NOINLINE void send_file_and_exit(const char *url, int what)
    signal(SIGPIPE, SIG_IGN);

    /* If not found, default is "application/octet-stream" */
-   found_mime_type = "application/octet-stream";
+   found_mime_type = "text/html";
    suffix = strrchr(url, '.');
    if (suffix) {
        static const char suffixTable[] ALIGN1 =

), damit dann ein Aufruf wie dieser:

busybox httpd -p 81 -h freetz.org

genutzt werden kann, um die Seiten auch über einen HTTP-Server (hier auf Port 81) bereitzustellen.

Das ist zwar alles kein echter Ersatz für ein voll funktionierendes Wiki mit allen Links (vor allem, weil noch genug Links übrigbleiben, die auf die "echte" Site unter freetz.org verweisen), aber ehe irgendwann die Daten gar nicht mehr abzurufen sind (auch die Wayback-Machine ist da keine allzu große Hilfe), kann man sich auch mal mit so einem lokalen Mirror helfen.

Da die dort veröffentlichten Seiten alle unter CC-BY-SA 2.0 stehen (siehe http://freetz.org/wiki/Impressum), ist die private Kopie ohnehin gar kein Problem und auch das erneute Veröffentlichen eines Archivs mit den gespiegelten Seiten als provisorisches Wiki (z.B. durch Einstellen in einen Freetz-Fork mit ein paar Shell-Skripten, die das wieder über einen Browser zugänglich machen, s.o.) sollte kein Problem darstellen, solange man dabei die Quelle nennt.

PS: Die Option "-E" beim "wget" will bei mir nicht richtig funktionieren, daher die Kopfstände mit der Änderung des Standard-Typs.

 

[Chatty]

Danke @PeterPawn. Ich verstehe sowie so nicht, warum das Freetz-Projekt nicht schon vor geraumer Zeit auf z.B. github wechselte. Dort ist alles vorhanden. Jemand kümmert sich um Fehler im CMS, das Hosting ist stabil usw.

Ich habe inzwischen mein jq zur Speicherung aller Benzinpreisänderungen in meiner Umgebung genutzt, so dass ein Schreibzugriff nur bei einer Änderung vorkommt. Diese werden im CSV-Format an eine Textdatei angehangen, so dass sich ein fortwährendes Logfile ergibt.

 

[FischersFreetz]

Hallo,
ich habe im aktuellen Freetz für eine 7490 und Firmware 7.12 das Paket "jq" (Version 1.6) ausgewählt. Zwar lief der Build durch, jedoch erhalte ich beim Starten von "iq" folgende Fehlermeldung;

# jq
jq: src/jv.c: 444: jvp_string_ptr: Assertion `jv_get_kind(a) == JV_KIND_STRING' failed.
Aborted

(Ein statisches Linken veränderte die Situation auch nicht.)

Hat jemand eine Ahnung, wie man "jq" erfolgreich zum Laufen bekommen könnte?

 

[rolex0815]

In der PM von @FischersFreetz hatte ich noch gesagt, daß ich leider auch nicht weiß, warum der Crash auftritt. Hat mich aber dazu angestachelt, mich auf die Suche zu begeben und siehe da:

root@FritzBox7590:/var/media/ftp/uStor-01# ./jq
jq - commandline JSON processor [version 1.6]

Usage:  ./jq [options] <jq filter> [file...]
        ./jq [options] --args <jq filter> [strings...]
        ./jq [options] --jsonargs <jq filter> [JSON_TEXTS...]

jq is a tool for processing JSON inputs, applying the given filter to
its JSON text inputs and producing the filter's results as JSON on
standard output.

The simplest filter is ., which copies jq's input to its output
unmodified (except for formatting, but note that IEEE754 is used
for number representation internally, with all that that implies).

For more advanced filters see the jq(1) manpage ("man jq")
and/or https://stedolan.github.io/jq

Example:

        $ echo '{"foo": 0}' | jq .
        {
                "foo": 0
        }

Es handelt sich anscheinend um einen gcc-Bug. Nach zeitmäßiger Eingrenzung kam ich auf die Idee das Binary mit freetz-ng zu erzeugen und das hat funktioniert. freetz-ng verwendet den gcc 8.3.0 - freetz "nur" 5.5.0. Alle Angaben beziehen sich auf meine Konfiguration.

Anbei das erzeugte binary.

/jq-1.6/root/usr/bin$ file jq 
jq: ELF 32-bit MSB executable, MIPS, MIPS32 rel2 version 1 (SYSV), statically linked, stripped

 

[FischersFreetz]

... angestachelt, mich auf die Suche zu begeben und siehe da: ...

Vielen Dank dafür...