PeterPawn
commented
4 years ago Falsches Repo, richtig wäre https://github.com/PeterPawn/YourFreetz
Bei OpenSSL 1.1.1 kommt ein neuer Mechanismus zum Konfigurieren des Builds zum Einsatz (es gibt jetzt ein Unterverzeichnis "Configurations", in dem man die eigenen Einstellungen an-/ablegen kann; https://github.com/openssl/openssl/tree/master/Configurations) - darauf muß/sollte man das in Freetz erst einmal umstellen (anstatt wie bisher die eigenen vier Konfigurationen in die "Configure" hineinzupatchen - der Aufbau dieser Konfigurationen und Templates ist in der oben verlinkten README.md im "Configurations"-Verzeichnis erklärt). Das Fehlschlagen/Fehlen der Patches für die Konfigurationsdateien ist dann auch der Grund, warum das bei Dir in die Hose geht - es gibt schlicht kein Target "linux-freetz-mips-asm" bisher und die Stellen, wo das zuvor hineingepatcht wurde, gibt es ebenfalls nicht mehr.
Ich habe bisher für GRX-Boxen (die ja dann auch noch "musl" als C-Library verwenden ab 07.20) noch nichts gemacht, eine Version für VR9 habe ich irgendwann mal (ohne Freetz) erstellt (müßte ich suchen, ich weiß gerade nicht, wo das war).
Man kann jedenfalls (wegen Konflikten in den Build-Optionen) bei OpenSSL auch nicht einfach das (durchaus vorhandene) "linux-mips32"-Target nehmen beim "Configure" (mal abgesehen davon, daß das von Freetz als "configure" verwurstet wird, obwohl es mit den üblichen "autoconf"-Mechanismen gar nichts zu tun hat) - dann kommt man zwar bis zum Compiler, aber irgendwo bei den Optionen gibt es dann einen weiteren Konflikt (iirc).
Das, was ich da für mich selbst bisher genutzt hatte, taugt also auch nicht wirklich für Freetz - zusätzlich bricht man sich, wenn man das für Freetz "so wie üblich" umsetzen wollte, wieder einen ab, weil dann wohl auch 0.9.8irgendwas wieder als heilige Kuh nicht geschlachtet werden darf - damit hat man dann drei OpenSSL-Versionen in dem Projekt (alles unter dem gemeinsamen Label "OpenSSL") und macht sich 'nen Häßlichen.
Ich werde also sicherlich irgendwann einen Patch für meinen Freetz-Fork bereitstellen und dann auch für die pre-built-Binaries benutzen. Aber der wird - mit ziemlicher Sicherheit - so aussehen, daß er die bisher verwendeten OpenSSL-Versionen komplett ersetzt ohne jede Rücksicht auf Verluste und dann das Bauen von älterer Firmware (die ja weiterhin auch 1.0.x-Versionen verwendet, was für alles vor 07.20 gilt) nur mit einem älteren Stand aus dem Repo möglich ist.
Wer das selbst in Angriff nehmen will, liest sich am besten zunächst mal die Beschreibung der neuen OpenSSL-Konfigurationsmöglichkeiten durch und erstellt dann eine (neue) Konfigurationsdatei für die verschiedenen Plattformen, die in Freetz unterstützt werden. Sinnvollerweise verwendet man hier aber tatsächlich gleich "FREETZ_SYSTEM_TYPE" zur Unterscheidung (bisher gründet das bei Freetz auf den Plattformen, also alle MIPS32-SoC werden als Eines behandelt), weil es einem die Option eröffnet, bei den GRX-Chipsets auch auf die Hardware-Unterstützung zuzugreifen (ob das tatsächlich auch außerhalb von AVM-Code machbar ist, prüfe ich noch immer).
Im nächsten Schritt wäre dann die "openssl.mk" anzupassen - selbst wenn man die "entkernt" und die 0.9.8/1.0.x rauswirft, sind die Optionen beim Konfigurieren andere und das "linux-freetz-vr9" (als Beispiel) muß man als Parameter ja auch noch übergeben. Auch ist es nicht wirklich hilfreich, beim Build die Dokumentation, die Beispiele, die Tests und irgendwelche Apps außer der eigentlichen "apps/openssl.c" als CLI-Version bauen zu lassen - das sollte man gleich beim Erstellen der Freetz-Konfigurationen berücksichtigen, dann wird das "Makefile" auch passend zusammengestrichen vom "Configure".
Will man das jedenfalls in das bestehende Freetz hineinfriemeln, müßte man in die bestehende "openssl.mk" noch die dritte Variante einbauen - in meinen Augen ein absoluter Albtraum. Da erscheint es mir logischer, ein neues Paket "openssl-1.1" einzuführen und beim bestehenden "openssl"-Paket die Verwendbarkeit auf FRITZ!OS-Versionen < 07.19 zu beschränken, während danach das neue Paket automatisch ausgewählt wird (als Standard).
Denn es kommt auch noch hinzu, daß vermutlich lange nicht alle anderen Pakete in Freetz auch mit OpenSSL 1.1.x kompatibel sind - zumindest nicht immer in den (teilweise schon recht alten) Versionen, die in Freetz verwendet werden. Daher ist ein "Parallelbetrieb" von AVM-Version und Freetz-Version von OpenSSL (den es früher auch schon gab, nur unter umgekehrtem Vorzeichen, wo dann Freetz die neueren Versionen bereithielt) vielleicht auch keine so schlechte Idee.
Alles das sind Punkte, auf denen man (und zwar bevor man da etwas in Angriff nimmt und nicht erst dann, wenn man schon mitten dabei ist) erst einmal etwas herumdenken sollte - für die Entscheidung, ob man das nun mit zwei OpenSSL-Versionen in einer Firmware angeht oder nicht, müßte man gar erst mal wissen, welche anderen Pakete bei einem "kompletten Umstieg" am Ende hinten runterfallen würden und dann überlegen, ob man das akzeptiert (und die Version mit weniger potentiellen Konflikten wählt) oder ob man das auf keinen Fall will und am Ende sogar irgendwelche uralten 0.9.8-Versionen weiterhin mit der (aktuellen) Freetz-Version erzeugt werden müssen, nur damit irgendwelche alten (und praktisch nicht mehr in nennenswerter Anzahl existierenden) FRITZ!Boxen weiterhin unterstützt werden.
Spätestens seit 06.8x (genau weiß ich den "Termin" für den Umstieg bei AVM gar nicht mehr) verwendet auch AVM schon die OpenSSL-Versionen 1.0.x - und wenn tatsächlich mal jemand (aus reinem Interesse und dann hoffentlich nicht für einen produktiven Einsatz, schon gar nicht "am Internet") eine ältere Version bauen lassen will, dann kann/muß er eben einen älteren Stand von Freetz benutzen.
Bevor jedenfalls solche Fragen nicht geklärt und die jeweiligen Positionen/Fronten klar sind, macht es auch (nach allen bisherigen Erfahrungen) nur sehr wenig Sinn, so etwas als Patch für Freetz bereitzustellen - es bringt außer viel Arbeit und jeder Menge Frust am Ende nichts.
Da das hier ohnehin das falsche Repo wäre, mache ich hier mal zu ... wenn Du (oder jemand anderes) das möchte, kann er/sie das gerne im richtigen Repo (s. erste Zeile) neu aufmachen (die Fehlernachricht beim "Configure" braucht's dann aber nicht erneut, man kann ja auch auf das hier verlinken).
MasterRoCcO
Hi Peter,
ich habe da mal eine frage ist es möglich das Openssl 1.0.2u auf 1.1.1g ein update bekommt. Ich versuche dieses nun seit ein paar tagen aber ich bekomme immer ein Fehler.
Configuring OpenSSL version 1.1.1g (0x1010107fL) for linux-freetz-mips-asm Using os-specific seed configuration Usage: Configure [no- ...] [enable- ...] [-Dxxx] [-lxxx] [-Lxxx] [-fxxx] [-Kxxx] [no-hw-xxx|no-hw] [[no-]threads] [[no-]shared] [[no-]zlib|zlib-dynamic] [no-asm] [no-egd] [sctp] [386] [--prefix=DIR] [--openssldir=OPENSSLDIR] [--with-xxx[=vvv]] [--config=FILE] os/compiler[:flags]
pick os/compiler from: BS2000-OSD BSD-generic32 BSD-generic64 BSD-ia64 BSD-sparc64 BSD-sparcv8 BSD-x86 BSD-x86-elf BSD-x86_64 Cygwin Cygwin-i386 Cygwin-i486 Cygwin-i586 Cygwin-i686 Cygwin-x86 Cygwin-x86_64 DJGPP MPE/iX-gcc UEFI UWIN VC-CE VC-WIN32 VC-WIN32-ARM VC-WIN32-ONECORE VC-WIN64-ARM VC-WIN64A VC-WIN64A-ONECORE VC-WIN64A-masm VC-WIN64I aix-cc aix-gcc aix64-cc aix64-gcc android-arm android-arm64 android-armeabi android-mips android-mips64 android-x86 android-x86_64 android64 android64-aarch64 android64-mips64 android64-x86_64 bsdi-elf-gcc cc darwin-i386-cc darwin-ppc-cc darwin64-ppc-cc darwin64-x86_64-cc gcc haiku-x86 haiku-x86_64 hpux-ia64-cc hpux-ia64-gcc hpux-parisc-cc hpux-parisc-gcc hpux-parisc1_1-cc hpux-parisc1_1-gcc hpux64-ia64-cc hpux64-ia64-gcc hpux64-parisc2-cc hpux64-parisc2-gcc hurd-x86 ios-cross ios-xcrun ios64-cross ios64-xcrun iossimulator-xcrun iphoneos-cross irix-mips3-cc irix-mips3-gcc irix64-mips4-cc irix64-mips4-gcc linux-aarch64 linux-alpha-gcc linux-aout linux-arm64ilp32 linux-armv4 linux-c64xplus linux-elf linux-generic32 linux-generic64 linux-ia64 linux-mips32 linux-mips64 linux-ppc linux-ppc64 linux-ppc64le linux-sparcv8 linux-sparcv9 linux-x32 linux-x86 linux-x86-clang linux-x86_64 linux-x86_64-clang linux32-s390x linux64-mips64 linux64-s390x linux64-sparcv9 mingw mingw64 nextstep nextstep3.3 sco5-cc sco5-gcc solaris-sparcv7-cc solaris-sparcv7-gcc solaris-sparcv8-cc solaris-sparcv8-gcc solaris-sparcv9-cc solaris-sparcv9-gcc solaris-x86-gcc solaris64-sparcv9-cc solaris64-sparcv9-gcc solaris64-x86_64-cc solaris64-x86_64-gcc tru64-alpha-cc tru64-alpha-gcc uClinux-dist uClinux-dist64 unixware-2.0 unixware-2.1 unixware-7 unixware-7-gcc vms-alpha vms-alpha-p32 vms-alpha-p64 vms-ia64 vms-ia64-p32 vms-ia64-p64 vos-gcc vxworks-mips vxworks-ppc405 vxworks-ppc60x vxworks-ppc750 vxworks-ppc750-debug vxworks-ppc860 vxworks-ppcgen vxworks-simlinux
NOTE: If in doubt, on Unix-ish systems use './config'.
ERROR: Build failed.
Ich habe auch schon mal bei freetz-ng angefragt aber da habe ich die Antwort bekommen
Nein, kann ich nicht. Ich hoffe aber nach wie vor dass @PeterPawn die irgendwann braucht ;-)