[Problem] Auffälligkeiten/Fehler bei Freetz-Build für 7590

FischersFreetz

Mitglied
Mitglied seit
22 Feb 2019
Beiträge
281
Punkte für Reaktionen
43
Punkte
28
Hallo,

ich habe für die 7590 ein Firmware-Image in der Version 7.12 gebaut, das klappte so weit so gut.
Jedoch sind mir zwei Sachen aufgefallen: Zum einen:

1. werden einige Hardware-Informationen bei der Box-Info nicht angezeigt
...freetzerror - boxinfo.png
und zum anderen

2. bricht der Build-Prozess fehlerhaft ab, wenn bei den php-Features der curl-Support ausgewählt wurde.
....freetzerror php-features - with curl support.PNG

Hat jemand einen Rat?
Oder hat ein "Entwickler" Zeit und Muse zur Korrektur?

Grüße
FischersFreetz

Bilder geschrumpft by stoney
 
Zuletzt bearbeitet von einem Moderator:
Du müßtest mal bitte mittels "fmake" ein Protokoll des Builds erstellen (es reicht der nächste und der muß nicht unbedingt "vorne" beginnen, also nach einem "make clean" o.ä.) ... die Frage hier wäre es, warum bei den Libraries für den Linker die "libpthread" nicht aufgeführt ist, welche die ganzen fehlenden Funktionen, deren Namen mit "pthread_..." beginnen, bereitstellen sollte. Nur steht halt die Zeile mit dem entsprechenden Aufruf weit oberhalb dessen, was man im Screenshot sehen kann.

Und wenn Du das Protokoll erstellst, bitte als Textdatei hier anhängen und nicht als CODE-Block einbetten - kein Mensch will in so einer Datei alles sequentiell lesen und eine Suche funktioniert mit einem Editor in einer Textdatei immer noch am besten.

Ich gehe auch davon aus, daß Du hier für dieses Projekt: https://github.com/Freetz/freetz nach Hilfe fragst (anhand der Angaben in #1 kann ich das nicht erkennen) ... nur dafür könnte/würde ich meinerseits Hilfe anbieten, weil da bei Freetz-NG (https://github.com/Freetz-NG/freetz-ng) viel geändert wurde und ich keine Lust habe, mich in zwei unterschiedliche Projekte "einzuarbeiten".

Die betreffende Datei https://github.com/Freetz-NG/freetz...d/files/root/usr/lib/cgi-bin/mod/box_info.cgi hat immerhin 10 Commits (wobei der letzte schon aus dem August 2019 wäre) seit dem Fork zu verzeichnen und die müßte man erst mal "nachvollziehen", um die Ursachen zu finden.

Wobei das Problem beim Linken ohne die "libpthread" bei beiden Projekten dieselbe Ursache haben könnte ... eben dieses Fehlen der Library. Wenn ich - ausgehend von den paar sichtbaren Zeilen - raten sollte, würde ich sagen, daß da jemand gegen die "libcurl" linken will (u.U. sogar statisch, wenn man sich den Dateinamen "libcurl.a" ansieht), ohne dabei die "libpthread" einzubeziehen (ggf. braucht's auch hier die statische Library "libpthread.a").

Zumal es bei der "uClibc-ng" auch irgendwann (iirc so um die 1.0.17 herum, wobei hier noch die 1.0.14 verwendet wurde von AVM) mal eine Diskussion gab hinsichtlich von Problemen beim statischen vs. dynamischen Linken bzw. bei "single threaded vs. multi threaded"-Code, wo bei "single threaded" die Aufrufe der pthread-Funktionen praktisch auf eine Dummy-Funktion gehen sollten, um bessere Performance zu erzielen (bei "single threaded code" muß man am Ende keine Threads miteinander synchronisieren). Das habe ich aber nur noch verschwommen "auf dem Schirm" und so sollte man besser erst mal in ein (richtiges) Protokoll sehen.
 
Einfach mal im Freetz-Verzeichnis ein "./fmake -h" aufrufen ... dann am besten, wenn's "ernst wird", die Optionen "-c -t" verwenden, womit das parallel auf der Console angezeigt und in eine Datei, mit Datum/Uhrzeit des Builds im Namen, geschrieben wird. Die Ausgabedatei ist dann das, was hier interessiert.
Code:
pi@pi4:/media/pi/extern_10_320/pi4/builds/vr9 $ ./fmake -h

fmake - Make wrapper for calling additional commands before/after build

Usage: fmake [options] [--] [make-options] [<target>]
    -l <log-file> - write output to <log-file> (default: fmake.log)
    -t            - append time stamp to log file name
                    (e.g. fmake_2012-02-10_12-25-20.log)
    -n            - no log file
    -c            - log to console (default: no)
    -h            - display this help text
    -x            - display sample fmake_post code (e-mail message)
    --            - separate fmake options from make options
    <target>      - make target(s) (optional)

Examples:
    fmake
        call "make" (default target), log to fmake.log, no console output
    fmake -l my.log -c precompiled
        call "make precompiled", log to my.log and to console in parallel
    fmake -n -c
        no log file, console output only
    fmake -n
        no log file, no console output (silent make)
    fmake -t mc-dirclean mc-precompiled
        make two targets, log to fmake_<timestamp>.log
    fmake -c -- FREETZ_FWMOD_SKIP_PACK=y -k firmware-nocompile
        log + console output, call make with environment variable + parameter

In all modes, the build will be timed (via "time") and the result printed
to the chosen output channels.

User-specified pre/post-make actions such as sending an e-mail notification
after a long build can be specified in files named fmake_pre and fmake_post.
The files are optional, but have to be executable if they exist. They may be
of any type, e.g. Bash/Perl/Python/Lua scripts or even compiled executables.
In fmake_post you may use the following environment variables:

    FMAKE_TARGET - make target(s)
    FMAKE_RESULT - make exit code (0=OK)
    FMAKE_TIME   - duration of build process
    FMAKE_LOG    - log file name, if any

pi@pi4:/media/pi/extern_10_320/pi4/builds/vr9 $
Wenn es um "original Freetz" geht, schaue ich mir das mit der "box_info.cgi" auch mal an - versuche mal bitte ein
Code:
/bin/sh -x /usr/lib/cgi-bin/mod/box_info.cgi
aufzurufen (in irgendeiner Shell, außer Rudi) und packe die Ausgabe davon (notfalls mit "2>filename 1>&2" die gesamte Ausgabe in eine Datei umleiten) auch mit in den nächsten Beitrag.

In dieser "box_info.cgi" liegt noch so manches im Argen ... angefangen bei der Abfrage des Firmware-Datums in der "/etc/version" bis hin zur Angabe/Annahme, daß die Größe des SPI-Flashs (sflash_size) irgendwie mit dem TFFS und seiner Größe korrelieren müsse (was u.U. in der Vergangenheit mal richtig war).

Da hat mindestens seit der 7412 keiner mehr richtig hingesehen (schon die hat keinen SPI-Flash mehr) und erst recht nicht, seitdem es die GRX- oder IPQ-Boxen (GRX ebenfalls vollkommen ohne SPI-Flash, bei den IPQ-Modellen hätte zumindest die 4040 noch welchen, wobei die wieder keinen NOR-Flash für's OS mehr hat) gibt.

Da will ich auch noch nicht wirklich etwas versprechen ... die Frage wäre, wie wichtig man diese Infos am Ende nimmt und ob es nicht - angesichts der breiter gewordenen Auswahl an möglichen Ergebnissen für die neueren Modelle - klüger wäre, auf diese Anzeigen ggf. ganz zu verzichten oder sie zumindest so zu gestalten, daß nicht länger eine Skript-Datei für alle Modelle passen soll/muß, denn das macht es nur deutlich komplizierter. Eine Datei für die "SoC-Generation" wäre da schon deutlich einfacher zu stricken und wenn man das noch auf > 07.0x beschränkt, braucht man auch die Angaben zum FRITZ!OS nicht länger an unterschiedlichen Stellen zusammenzuklauben. Nur paßt das dann so gar nicht mehr zur bisherigen Vorgehensweise mit dem "one script fits all models" bei den Freetz-Modifikationen.
 
Hier nun die beiden Dateien.

(Die Box-Informationen sind wohl eher kosmetischer Natur. Wenn sie fehlen oder fehlerhaft sind, kommen u.U. Zweifel an der Pflege des Projektes auf.)
 

Anhänge

  • fmake_2020-04-25_08-24-40.txt
    28.8 KB · Aufrufe: 4
  • box_info.txt
    18.5 KB · Aufrufe: 6
Versuche mal in der Datei "make/php/php.mk" die Zeile 23 folgendermaßen zu ergänzen:
Rich (BBCode):
$(PKG)_EXTRA_LDFLAGS += -all-static -lpthread
Theoretisch sollte das Staging-Directory der Toolchain schon im Suchpfad für Libraries enthalten sein und auch die "libpthread.a" sollte sich dort finden lassen - aber wenn das mit der Suche im richtigen Verzeichnis nicht funktioniert mit dieser einen Änderung, füge hinter dieser Zeile (aber vor der mit dem "endif") noch eine weitere hinzu (der Einfachheit halber, theoretisch ginge auch alles auf einer oder alles auf drei verschiedene aufgeteilt):
Code:
$(PKG)_EXTRA_LDFLAGS += -L$(TARGET_TOOLCHAIN_STAGING_DIR)/usr/lib
Damit müßte zumindest das statische Linken für das CGI-Binary wieder funktionieren und auch für ältere C-Libraries (also in erster Linie uClibc 0.9.irgendwas) sollte diese Ergänzung unschädlich sein. Ich würde das Problem tatsächlich auf dem Umstieg auf die uClibc-ng und das oben schon mal erwähnte Problem mit diesem Projekt beim statischen vs. dynamischen Linken zurückführen.

Die "box_info.cgi" schaue ich mir heute nachmittag mal an - ich muß erst mal meine 7580 als GRX-Box hervorkramen, um die Änderungen an dieser Stelle dann selbst testen zu können (in erster Linie die modellabhängigen Ausgaben der jeweiligen Kommandos in dieser Datei).

EDIT: Ach so ... bei Fehlern natürlich bitte auch wieder das Protokoll des "fmake" zeigen.

EDIT2: Ich habe mal den Link zum Thread aus der Mailing-Liste der "uClibc-ng" herausgesucht: https://mailman.uclibc-ng.org/pipermail/devel/2016-August/001132.html

===========================================================================

Die Stelle mit dem "TFFS" wäre eigentlich nur zu entfernen/zu überspringen, weil der Eintrag wahrscheinlich ohnehin eher "SPI" heißen sollte als "TFFS".

Kompliziert wird es bei den GRX-Boxen aber spätestens da, wo es um die Taktfrequenzen geht. Die haben ja nun mehrere Cores (i.d.R. 4) und gleichzeitig eine dynamische und lastabhängige Stromsparmöglichkeit, die natürlich auch den Takt dann entsprechend herunterregelt (ja, es gibt sogar ein Herunterregeln/Begrenzen der Taktfrequenzen - in /etc/init.d/rc.ovh_control.sh - bei Überhitzung) - ähnlich "SpeedStep" bei Intel-Prozessoren.

Da stellt sich dann schon direkt die Frage, was man da ausgeben sollte/will - ist es die aktuelle Taktfrequenz für jeden Core oder doch die maximale?
Code:
# cat /sys/devices/system/cpu/cpu[0-3]/cpufreq/cpuinfo_max_freq
1000000
1000000
1000000
1000000
# cat /sys/devices/system/cpu/cpu[0-3]/cpufreq/cpuinfo_cur_freq
333333
333333
333333
333333
#
Oder gibt man eher die Temperaturen mit aus oder doch besser die Statistiken, wie lange sich die CPU jeweils in welchem Zustand befand in der letzten Zeit und wie oft dieser Zustand wechselte?
Code:
# cat /proc/avm/temp_sensors
CPU                                                             : 61.0 ��C
Wifi-5GHz                                                       : 47.0 ��C
Wifi-2.4GHz                                                     : 38.0 ��C
# cat /proc/chip_temperature
Reading Temperatures:
Channel 0: 58.50 ��C (Raw Value: 3603)
Channel 1: 60.75 ��C (Raw Value: 3598)
# cat /sys/devices/system/cpu/cpu[0-3]/cpufreq/stats/total_trans
1553
1553
1553
1553
# cat /sys/devices/system/cpu/cpu[0-3]/cpufreq/stats/time_in_state
{Frequency TimeInFrequencyState TemperatureMin(1/10 ��) TemperatureSum(1/10 ��) TemperatureMeasurements TemperatureMax(1/10 ��)}[4]:
1000000 8860 582 118337 192 655 666666 8001 602 109502 177 655 333333 8280 590 111073 184 632 200000 44861 580 323539 546 610
{Frequency TimeInFrequencyState TemperatureMin(1/10 ��) TemperatureSum(1/10 ��) TemperatureMeasurements TemperatureMax(1/10 ��)}[4]:
1000000 8860 582 118337 192 655 666666 8001 602 109502 177 655 333333 8280 590 111073 184 632 200000 44861 580 324129 547 610
{Frequency TimeInFrequencyState TemperatureMin(1/10 ��) TemperatureSum(1/10 ��) TemperatureMeasurements TemperatureMax(1/10 ��)}[4]:
1000000 8860 582 118337 192 655 666666 8001 602 109502 177 655 333333 8280 590 111073 184 632 200000 44861 580 324719 548 610
{Frequency TimeInFrequencyState TemperatureMin(1/10 ��) TemperatureSum(1/10 ��) TemperatureMeasurements TemperatureMax(1/10 ��)}[4]:
1000000 8860 582 118337 192 655 666666 8001 602 109502 177 655 333333 8280 590 111073 184 632 200000 44861 580 325309 549 610
#
Es gibt an dieser Stelle (und für diese SoC-Familie) so viele unterschiedliche Quellen und ggf. sinnvolle Anzeigen (ich würde schwören, daß ich bei einer "tatsächlich arbeitenden Box" auch schon unterschiedliche Statistiken für die 4 Cores gesehen habe), daß die Entscheidung schwer fällt - das Einzige, was hier definitiv keinen Sinn macht, ist ein Test auf "/proc/clocks" oder der Zugriff auf "cpufrequency" bzw. "sysfrequency", wie er bisher in der "box_info.cgi" erfolgt.

Man müßte sich also als Allererstes mal überlegen, welche Werte man da überhaupt anzeigen lassen will bzw. wieviele - erst danach machen irgendwelche Anpassungen an das spezielle Design der GRX-Chipsets (und natürlich an die dort von AVM eingebundenen Treiber und Datenquellen) irgendeinen Sinn. Hier bin ich dann "raus", weil ich die Freetz-Mods nicht benutze und daher auch keine wirkliche Meinung habe, was man da alles anzeigen sollte oder müßte und auch nicht, wie man das besser an die jeweils tatsächlich vorhandene "Hardware" (denn dafür sollen die Infos ja an dieser Stelle gesammelt werden) anpaßt, um damit mehreren Modellen und mehreren FRITZ!OS-Versionen (die unterschiedliche Datenquellen bereitstellen) gerecht zu werden.

Ich persönlich würde das jedenfalls nicht alles in einem "großen" Skript machen wollen, sondern mindestens anhand des SoC-Typs ein "spezialisiertes" aufrufen - meinetwegen könnten die auch alle gleichzeitig in der Firmware enthalten sein und diese Entscheidung damit erst zur "run-time" gefällt werden, wenn man "/proc/cpuinfo" auslesen kann, denn Platzmangel ist heutzutage nur noch in sehr extremen Ausnahmefällen ein Thema.
 
Zuletzt bearbeitet:
Erstmal Danke für Deine Überlegungen...

bezgl. Curl-Support bei den php-Features
Versuche mal in der Datei "make/php/php.mk" die Zeile 23 folgendermaßen zu ergänzen: ...
Die zwei obigen Vorschläge brachten leider nicht den erhofften Erfolg, der Build bricht wieder ab (das Protokoll hängt an).

bzgl. Box-Info
Da stellt sich dann schon direkt die Frage, was man da ausgeben sollte/will ...
Der Einfachheit halber wäre die Maximalfrequenz für mich am sinnvollsten.
 

Anhänge

  • fmake_2020-04-25_20-01-56.txt
    29.2 KB · Aufrufe: 4
Überprüfe mal, ob es (a) die Datei "toolchain/build/mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/mips-linux-uclibc/usr/lib/libpthread.a" bei Dir überhaupt gibt und (b), welche Object-Files darin enthalten sind (ar tv toolchain/build/mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/mips-linux-uclibc/usr/lib/libpthread.a).

Wenn die Datei existiert und auch noch ein "pthread_mutex_lock.os"-Member enthalten ist, hänge mal noch ein:
ar p toolchain/build/mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/mips-linux-uclibc/usr/lib/libpthread.a pthread_mutex_lock.os > /tmp/test;objdump -x /tmp/test
dran - das liest diesen einen Member aus der Bibliothek und analysiert seinen Inhalt ... interessant ist hier, ob es ein Symbol mit dem Namen "pthread_mutex_lock" im Object-File gibt.

Am besten ist es sogar noch, wenn man beim "objdump" das vom Cross-Compiler, also "toolchain/build/mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/mips-linux-uclibc/bin/mips-linux-objdump", verwendet, dieses erkennt dann die Architektur des Zielsystems auch noch korrekt.

Das zusätzliche Linkerverzeichnis kannst Du wieder rausnehmen (die zweite Zeile, die Du geändert haben wirst) - das Staging-Directory muß bereits Bestandteil des Suchpfads für Bibliotheken sein, denn die ganzen anderen Referenzen, die sich am Ende des "libtool"-Aufrufs finden:
Code:
[...] sapi/cli/ps_title.lo sapi/cli/php_cli_process_title.lo -lcrypt -lcrypt -liconv -lcurl -lpcre -lm -ldl -lcurl -lcrypt -lcrypt  -o sapi/cli/php
finden ihre Libs ja auch - schon die "libcurl.a", in der die fehlenden Symbole ja dann auffallen, ist da das beste Beispiel. Diesen Zusatz braucht's also ganz bestimmt doch nicht.

Ich habe mal einen Build für die GRX-Toolchain bei mir angeworfen, der läuft aber auf einem RasPi 4 und kann noch etwas brauchen - erst dann kann ich da genau sehen, welche Dateien im Staging-Directory für die Toolchain gelandet sind.

Hattest Du eigentlich bei Dir "from scratch" begonnen oder irgendwelche älteren Verzeichnisse wiederverwendet?
 
zu (a): Nein, die Datei "libpthread.a" ist dort nicht zu finden.
zu (b): (Eine Antwort erübrigt sich wohl.)

Ja, ich begann von Grund auf neu (mal abgesehen von einem Minimal-Image am Anfang).
 
Na dann muß man mal schauen, wieso es bei Dir diese Datei nicht gibt - das wäre ja genau diejenige, die beim statischen Linken (--all-static) die gesuchten "pthread_..."-Funktionen bereitstellen sollte.

Bei mir (allerdings auch basierend auf meinem eigenen Fork, aber der sollte an dieser Stelle identisch sein mit dem Original) ist die Datei jedenfalls auch in allen Toolchains für die SoCs, die ich "benutze", zu finden:
Code:
pi@pi4:/media/pi/extern_10_320/pi4/builds $ find . -name "libpthread.a"
./vr9/toolchain/build/mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/mips-linux-uclibc/target-utils/usr/lib/libpthread.a
./vr9/toolchain/build/mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/mips-linux-uclibc/lib/libpthread.a
./vr9/source/toolchain-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/uClibc-ng-1.0.14/lib/libpthread.a
./puma6/toolchain/build/i686_gcc-5.5.0_uClibc-1.0.14-nptl/i686-linux-uclibc/target-utils/usr/lib/libpthread.a
./puma6/toolchain/build/i686_gcc-5.5.0_uClibc-1.0.14-nptl/i686-linux-uclibc/lib/libpthread.a
./puma6/source/toolchain-i686_gcc-5.5.0_uClibc-1.0.14-nptl/uClibc-ng-1.0.14/lib/libpthread.a
./grx5/toolchain/build/mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/mips-linux-uclibc/target-utils/usr/lib/libpthread.a
./grx5/toolchain/build/mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/mips-linux-uclibc/lib/libpthread.a
./grx5/source/toolchain-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/uClibc-ng-1.0.14/lib/libpthread.a
./vx180/toolchain/build/mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mips-linux-uclibc/target-utils/usr/lib/libpthread.a
./vx180/toolchain/build/mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mips-linux-uclibc/lib/libpthread.a
./vx180/source/toolchain-mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/uClibc-0.9.33.2/lib/libpthread.a
pi@pi4:/media/pi/extern_10_320/pi4/builds $
Mir fällt im Moment kein plausibler Grund ein, warum beim "make all" für "uClibc-ng-1.0.14" bei Dir keine "libpthread.a" erzeugt werden sollte. Vielleicht mußt Du doch noch einmal den kompletten Build der Toolchain mit "fmake" protokollieren lassen - irgendwo da drin sollte sich ein "ar cr" nach einem "rm" für diese Bibliothek finden lassen.

Wobei ich mich beim "usr/lib" oben auch (mehrfach, weil ich kopiert hatte) vertan habe ... die Datei sollte unter "toolchain/build/mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/mips-linux-uclibc/lib/libpthread.a" liegen - da fehlt ein "usr" mittendrin ggü. #9. Am besten nimmst Du auch mal ein "find" (siehe Code-Kasten) für die Suche nach der Library.

Wobei das auch nur für die (nachträgliche) Suche nach der Datei eine Rolle spielt, denn für den Linker bzw. für "libtool" sollte automatisch das richtige Verzeichnis bei der Suche nach Bibliotheken eingeschlossen werden - daher erwarte ich auch unter dem korrekten Pfad eigentlich nicht, daß da eine passende "libpthread.a" existiert.
 
Die Datei "libpthread.a" finde ich im "richtigen" Verzeichnis:
Code:
$ find . -name "libpthread.a"
./source/toolchain-mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/uClibc-ng-1.0.14/lib/libpthread.a
./toolchain/build/mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/mips-linux-uclibc/lib/libpthread.a
(Wie ändert das die Situation bei der Fehleranalyse?)
 
Dann mache Dir doch einfach selbst ein Bild davon, wo das Problem liegt. Die Erklärungen und die notwendigen Recherchen sind ganz einfach.

Die Fehlermeldungen besagen, daß beim Linken bestimmte Symbole (Namen von Funktionen, die anderer Code aufrufen kann) nicht gefunden werden. Das löst man i.d.R. dadurch auf, daß man die Namen von Bibliotheken, in denen diese einzelnen Funktionen zusammengefaßt wurden, zusätzlich beim Linken angibt, genau dazu dient die Option mit dem "kleinen L". Da wird dann nach einer Bibliothek mit dem Namen "lib<name>.a" gesucht. Unter https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html ist das hinsichtlich der Option "-l" schön erklärt.

Die Option "--all-static" für das Hilfsprogramm "libtool" besagt, daß alles statisch gelinkt werden soll für das zu erzeugende Programm: https://www.gnu.org/software/libtool/manual/html_node/Link-mode.html - damit ist also auch mit einem "-lpthread" klar (ich hoffe mal, daß Du das auch als kleines L gesehen bzw. einfach aus meinem Beitrag kopiert hast - ansonsten hättest Du bei Unklarheiten sicherlich nachgefragt - und ich hatte das tatsächlich meinerseits in Deinem Protokoll aus #8 auch überprüft, daß sich da wirklich der richtige hexadezimale Wert hinter dem "l" verbarg), daß da nach einer Datei "libpthread.a" gesucht werden sollte.

Wenn dem "libtool" also richtig bekanntgegeben wurde, wo es diese Bibliotheken generell finden kann (-L) und nach welchen Dateien es suchen soll (-l), dann sollte man annehmen, daß dieses Programm die Bibliothek auch findet. Meinetwegen stelle Dir die Bibliothek einfach als ein Buch vor, das jetzt aber auch noch den richtigen Inhalt haben muß, damit der Leser damit etwas anfangen kann - das sieht man dem Buch von außen ja nicht an, was da drin steht ... selbst wenn man es am beschriebenen Ort (-L) und mit dem richtigen Titel (-l) gefunden hat (alle Optionen findest Du auch beim o.a. Link zur Beschreibung von "libtool").

Die für mich naheliegendste Vermutung ist es erst einmal, daß der Linker und das Programm "libtool" korrekt arbeiten ... also wäre die erste Annahme, die man jetzt überprüfen muß, diejenige, daß die nunmehr gefundene "libpthread.a" auch die passenden Funktionen enthält ... die dazu notwendigen Kommandos (zur Anzeige der enthaltenen Funktionen (ar tv) und zum Extrahieren und Prüfen eines einzelnen Members mit einer Funktion, die hier angeblich nicht gefunden wird (ar p mit anschließendem objdump)) habe ich bereits weiter oben aufgezeigt.

Wenn sich dabei dann herausstellen sollte, daß (a) Deine Änderungen im Makefile korrekt waren (was ich als "geprüft" abgehakt habe) und (b) die gefundene "libpthread.a" die richtigen Inhalte hat (es gibt da auch noch eine "libpthread_nonshared.a", die aber die Funktionen für Multi-Threaded-Programme gerade nicht enthält - nur sollte die nicht ausgewählt werden vom Linker, zumindest nicht, wenn frühzeitig die andere MIT den notwendigen Funktionen hinzugefügt wurde), dann kann/muß man weiter darüber nachdenken, warum das "libtool" an dieser Stelle (ggf. auch nur bei Dir, insofern wäre es vermutlich auch nicht verkehrt, wenn jetzt mal die von Dir verwendete ".config" dazukommt - spätestens wenn man das "richtig" nachstellen wollte, braucht man die ohnehin) die gefundenen Funktionen nicht akzeptieren will. Der nächste Schritt wäre es dann für mich, daß man da noch ein "--verbose" zum Aufruf von "libtool" hinzufügt, damit das etwas ausführlicher protokolliert, welche Dateien es wo sucht und findet (das geht notfalls auch bis zum "--debug" ... all diese Optionen findest Du in der Dokumentation des oben bereits verlinkten "libtool", wenn Du es nachlesen möchtest).

Ich weiß hier aus dem Stand auch nicht, wer da u.U. die "libpthread.a" und die "libpthread_nonshared.a" gegeneinander ausgetauscht haben könnte oder warum das "libtool" vielleicht zur falschen greift (von einer Option, die bei statischem Linken automatisch einen Suffix "_nonshared" an den Namen einer Bibliothek hängt, weiß ich nichts - ist mir vielleicht aber auch nur noch nicht untergekommen) ... nur kläre ich vor der Suche nach den unwahrscheinlicheren Ursachen (und sei es nur, daß die für MICH unwahrscheinlicher erscheinen, weil mir auch noch lange nicht alle denkbaren Fehler selbst passiert sind in meinem Leben) erst einmal diejenigen ab, die sich als "Annahmen" in die ganze Konstruktion eingeschlichen haben (die aber trotzdem unbestätigt sind) und die man aber sehr leicht überprüfen kann.

Den Ärger, daß sich hinterher eine dieser Annahmen als falsch herausstellt, erspare ich mir gerne - das nenne ich dann "gründliches und systematisches Vorgehen". Das muß nicht jeder so machen ... vielleicht findest Du auch jemanden, der das lieber durch Raten lösen möchte oder der tatsächlich dieses Fehlerbild bereits selbst lösen mußte und seine Lösung paßt bei Dir auch - der kann Dir dann vielleicht auch ohne dieses schrittweise Vorgehen helfen - nur ich wäre das nicht und bisher drängeln sich die Leute nach meinem Empfinden hier auch nicht.

EDIT: Auch eine gründlichere Lektüre des Mailinglisten-Threads zur "uClibc-ng" und "pthread"-Problemen beim statischen Linken bringt bei mir nur die Erkenntnis, daß dort exakt dasselbe vorgeschlagen wird als Lösung bei solchen Problemen, was ich hier mit Dir auch versuchen wollte und was aber offenbar nicht sofort zum Erfolg führt(e): https://mailman.uclibc-ng.org/pipermail/devel/2016-August/001147.html - dort wird auch die (naheliegende, deshalb war das ja auch mein erster Ansatz) Lösung empfohlen, beim Linken explizit die pthread-Library hinzuzufügen.
 
Zuletzt bearbeitet:
Ok, ich versuche am Ball zu bleiben....
Code:
$ ar p toolchain/build/mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/mips-linux-uclibc/usr/lib/libpthread.a pthread_mutex_lock.os > /tmp/test;
$ objdump -x /tmp/test >objdump.txt
Code:
...
SYMBOL TABLE:
...
000005f4 g     F .text  000002b8 pthread_mutex_lock

RELOCATION RECORDS FOR [.text]:
OFFSET   TYPE              VALUE
00000000 UNKNOWN           _gp_disp
00000004 UNKNOWN           _gp_disp
00000014 UNKNOWN           __stack_chk_guard
000000a0 UNKNOWN           __lll_robust_lock_wait
000001b0 UNKNOWN           __lll_robust_lock_wait
00000320 UNKNOWN           errno
00000444 UNKNOWN           __pthread_current_priority
00000460 UNKNOWN           __pthread_current_priority
00000464 UNKNOWN           __pthread_tpp_change_priority
0000049c UNKNOWN           __pthread_tpp_change_priority
000004a0 UNKNOWN           __pthread_tpp_change_priority
000004b4 UNKNOWN           __pthread_tpp_change_priority
000005b8 UNKNOWN           __stack_chk_fail
000005bc UNKNOWN           __stack_chk_fail
000005f4 UNKNOWN           _gp_disp
000005f8 UNKNOWN           _gp_disp
00000600 UNKNOWN           __stack_chk_guard
00000648 UNKNOWN           .text
00000660 UNKNOWN           .text
00000664 UNKNOWN           __pthread_mutex_lock_full
000006b0 UNKNOWN           __lll_lock_wait
000006b8 UNKNOWN           __lll_lock_wait
00000728 UNKNOWN           __lll_lock_wait
0000072c UNKNOWN           __lll_lock_wait
00000748 UNKNOWN           __is_smp
000007ec UNKNOWN           __lll_lock_wait
000007f4 UNKNOWN           __lll_lock_wait
00000888 UNKNOWN           __stack_chk_fail
0000088c UNKNOWN           __stack_chk_fail


RELOCATION RECORDS FOR [.pdr]:
OFFSET   TYPE              VALUE
00000000 UNKNOWN           .text
00000020 UNKNOWN           __pthread_mutex_lock
:rolleyes: Enthält die "libpthread.a" nun die richtigen Inhalte? Bei der konkreten Deutung der Informationen bin ich überfragt (mal ganz abgesehen von all den Zusammenhängen bem Buildprozess).
... Die Erklärungen und die notwendigen Recherchen sind ganz einfach. ...
( Dazu fällt mir in erster Linie die Relativitätstheorie ein. ;) )

Aber die ".config" konnte ich anhängen.
 

Anhänge

  • objdump.txt
    3.8 KB · Aufrufe: 0
  • .config.txt
    69.8 KB · Aufrufe: 2
Zuletzt bearbeitet:
Ja, der Member enthält offensichtlich das gesuchte Symbol. Damit stellt sich wieder die Frage, ob/warum das "libtool" hier dieses Symbol beim Linken nicht finden kann. Irgendwelche "Dekorationen" des Namens erkenne ich nicht im Fehlerprotokoll und wenn sich nicht etwas grundlegend gegenüber meinem alten Kenntnisstand, daß es innerhalb einer Library egal ist, wie die einzelnen Member heißen, weil nur die vorhandenen Symbole eine Rolle spielen und diese ohnehin alle vom Linker "geladen" werden, wenn es um das Auflösen von Referenzen geht, geändert hat, sollte der ja dieses Symbol finden können und trotzdem behauptet er steif und fest, das wäre "undefined".

Also bleibt wohl doch nichts anderes, als da mal die Option "--verbose" den "EXTRA_LDFLAGS" (s.o., die Schreibweise beinhaltet noch den Paketnamen) hinzuzufügen und darauf zu hoffen, daß dabei schon ersichtlich wird, welche Dateien "libtool" dann findet und durchsucht bei der Fahndung nach dem fehlenden Symbol. Wenn das nicht reichen sollte, braucht es ggf. auch das schon erwähnte "--debug" - ich würde es trotzdem erst mal mit "--verbose" probieren, weil das garantiert weniger zu lesenden und zu verstehenden Text ausgibt.

Wobei mir gerade beim Zurückblättern noch aufgefallen ist, daß ich das mit dem zusätzlichen "usr"-Verzeichnis als Ebene ja schon in #6 falsch angegeben hatte (zur Frage, worin sich "/lib" und "/usr/lib" bei einem Linux-System unterscheiden, kann man in den LSB-Definitionen nachlesen - dann versteht man ggf., warum ich (zugegebenermaßen ohne das zu überprüfen) zuerst von "/usr/lib" als Verzeichnis ausgegangen bin) ... ich kann es mir zwar nicht wirklich vorstellen, daß das "richtige" Staging-Directory nicht in der Suchreihenfolge enthalten ist, aber wenn man wirklich gründlich sein will, könnte man das auch noch einmal mit dem korrekten Pfad in der "-L"-Option versuchen (wobei ich mir davon nicht viel verspreche, das ist mehr die gefundene "Schwachstelle" bei der Suche nach anderen plausiblen Erklärungen).

Ich versuche auch heute abend mal, mit der Konfiguration den Build nachzustellen ... mit Glück stehe ich dann vor demselben Problem und kann mir das lokal, ohne weitere Nachfragen, bei mir ansehen. Aber das dauert noch und jetzt habe ich erst einmal anderes zu tun - daher mußt Du Dir selbst überlegen, ob Du einen weiteren Versuch mit "--verbose" startest oder abwarten willst, bis ich bei mir zu einem entsprechenden Test gekommen bin und damit klar wird, ob das auf ein "works for me" hinausläuft oder nicht.

EDIT: Mit einem
Code:
pi@pi4:/media/pi/extern_10_320/pi4/builds/grx5 $ toolchain/build/mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/mips-linux-uclibc/bin/mips-linux-objdump -t toolchain/build/mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/mips-linux-uclibc/lib/libpthread.a | grep ".* g .* pthread_"
00000000 g     F .text  0000005c .hidden pthread_atfork
00000000 g     F .text  000000f8 pthread_attr_getaffinity_np
00000000 g     F .text  00000148 pthread_attr_setaffinity_np
00000000 g     F .text  000000a8 pthread_getaffinity_np
00000104 g     F .text  000000e0 pthread_setaffinity_np
00000000 g     F .text  00000078 pthread_getcpuclockid
00000000 g     F .text  000000c8 pthread_kill
00000000 g     F .text  0000004c pthread_yield
00000000 g     F .text  00000100 pthread_sigqueue
00000000 g     F .text  00000028 pthread_spin_lock
00000000 g     F .text  00000034 pthread_spin_trylock
00000000 g     F .text  0000010c pthread_barrier_destroy
00000000 g     F .text  00000094 pthread_barrier_init
00000000 g     F .text  000001d8 pthread_barrier_wait
00000000 g     F .text  000002cc pthread_rwlock_timedrdlock
00000000 g     F .text  000002b8 pthread_rwlock_timedwrlock
00000000 g     F .text  000000e4 pthread_sigmask
00000000 g     F .text  0000004c pthread_spin_destroy
00000000 g     F .text  00000050 pthread_spin_init
00000000 g     F .text  00000054 pthread_spin_unlock
00000000 g     F .text  0000005c pthread_attr_setstackaddr
0000004c g     F .text  00000194 pthread_timedjoin_np
00000000 g     F .text  00000110 pthread_rwlock_trywrlock
00000000 g     F .text  00000054 pthread_barrierattr_getpshared
00000000 g     F .text  00000104 pthread_seteuid_np
00000000 g     F .text  00000060 pthread_mutexattr_gettype
00000000 g     F .text  00000054 pthread_rwlockattr_getkind_np
00000000 g     F .text  00000128 pthread_setcancelstate
00000000 g     F .text  00000070 pthread_mutex_destroy
00000000 g     F .text  00000074 pthread_mutexattr_settype
00000000 g     F .text  00000060 pthread_rwlockattr_setkind_np
00000000 g     F .text  00000084 pthread_mutexattr_setrobust
00000000 g     F .text  00000060 pthread_attr_setstacksize
00000000 g     F .text  0000004c pthread_barrierattr_destroy
00000000 g     F .text  00000050 pthread_barrierattr_init
00000670 g     F .text  00000050 pthread_mutex_unlock
000005f4 g     F .text  000002b8 pthread_mutex_lock
00000000 g     F .text  00000058 pthread_mutexattr_getprotocol
00000000 g     F .text  00000944 pthread_mutex_timedlock
00000000 g     F .text  000000c0 pthread_detach
00000000 g     F .text  00000054 pthread_attr_getschedpolicy
00000000 g     F .text  000000dc pthread_tryjoin_np
00000000 g     F .text  000000e4 pthread_attr_setschedparam
00000000 g     F .text  0000007c pthread_mutexattr_setpshared
00000000 g     F .text  00000050 pthread_equal
00000000 g     F .text  00000080 pthread_mutex_consistent
00000000 g     F .text  00000050 pthread_self
00000000 g     F .text  00000600 pthread_mutex_trylock
00000000 g     F .text  00000068 pthread_attr_destroy
00000000 g     F .text  00000138 pthread_cancel
00000000 g     F .text  000001b4 pthread_getschedparam
00000000 g     F .text  0000004c pthread_rwlock_destroy
00000000 g     F .text  00000058 pthread_condattr_getclock
00000000 g     F .text  000000b4 pthread_rwlock_init
00000000 g     F .text  0000004c pthread_rwlockattr_destroy
00000000 g     F .text  0000006c pthread_attr_setschedpolicy
00000000 g     F .text  00000074 pthread_condattr_setclock
00000000 g     F .text  000000cc pthread_key_create
00000000 g     F .text  00000054 pthread_rwlockattr_init
00000000 g     F .text  00000064 pthread_attr_getstacksize
00000000 g     F .text  00000058 pthread_attr_getdetachstate
00000000 g     F .text  00000060 pthread_attr_getstack
00000000 g     F .text  000000d0 pthread_getspecific
00000000 g     F .text  00000054 pthread_rwlockattr_getpshared
00000000 g     F .text  00000050 pthread_getconcurrency
00000000 g     F .text  00000140 pthread_setspecific
00000000 g     F .text  00000060 pthread_rwlockattr_setpshared
00000000 g     F .text  00000060 pthread_setconcurrency
00000000 g     F .text  00000194 pthread_setschedparam
00000000 g     F .text  00000054 pthread_attr_getguardsize
00000000 g     F .text  0000004c pthread_condattr_destroy
00000000 g     F .text  00000050 pthread_attr_setguardsize
00000074 g     F .text  000001c0 pthread_join
00000000 g     F .text  00000068 pthread_condattr_init
00000000 g     F .text  00000104 pthread_setegid_np
00000000 g     F .text  00000070 pthread_attr_getschedparam
00000000 g     F .text  00000058 pthread_condattr_getpshared
00000000 g     F .text  00000074 pthread_attr_setstack
00000000 g     F .text  00000070 pthread_condattr_setpshared
00000000 g     F .text  00000078 pthread_mutexattr_setprotocol
00000000 g     F .text  000000b0 pthread_mutexattr_getprioceiling
00000000 g     F .text  00000058 pthread_attr_getinheritsched
00000000 g     F .text  0000006c pthread_exit
00000000 g     F .text  00000058 pthread_attr_getscope
00000000 g     F .text  000000e4 pthread_mutexattr_setprioceiling
00000000 g     F .text  00000078 pthread_attr_setinheritsched
00000000 g     F .text  00000184 pthread_setschedprio
00000000 g     F .text  00000128 pthread_rwlock_tryrdlock
00000000 g     F .text  000003a4 pthread_getattr_np
00000000 g     F .text  000001b0 pthread_mutex_init
00000000 g     F .text  000000a4 pthread_key_delete
00000000 g     F .text  00000078 pthread_attr_setscope
00000000 g     F .text  00000060 pthread_barrierattr_setpshared
00000000 g     F .text  0000004c pthread_mutexattr_destroy
00000000 g     F .text  00000130 pthread_setcanceltype
00000000 g     F .text  00000050 pthread_mutexattr_init
00000000 g     F .text  00000058 pthread_mutexattr_getrobust
00000000 g     F .text  00000058 pthread_mutexattr_getpshared
00000000 g     F .text  0000007c pthread_attr_setdetachstate
00000000 g     F .text  00000054 pthread_attr_getstackaddr
00000000 g     F .text  000000b0 pthread_testcancel
pi@pi4:/media/pi/extern_10_320/pi4/builds/grx5 $
kannst Du Dir alle globalen Symbole (deren Name mit "pthread_" beginnt) in der Library "libpthread.a" anzeigen lassen ... ich finde darin jedenfalls alle Symbole, die der Linker in Deinem Fehlerprotokoll als fehlend bemängelt hat (und die sind auch "sichtbar" und nicht "hidden", wie z.B. das "pthread_atfork" oben) und eine richtig plausible Erklärung, warum der Linker sie dann nicht finden will, fällt mir dazu nicht ein.

EDIT2: Nein, Korrektur ... für "pthread_create" gilt das nicht, das ist in der Library als "weak" vorhanden:
Code:
pi@pi4:/media/pi/extern_10_320/pi4/builds/grx5 $ for sym in pthread_create pthread_detach pthread_join pthread_mutex_destroy pthread_mutex_init pthread_mutex_lock pthread_mutex_unlock; do toolchain/build/mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/mips-linux-uclibc/bin/mips-linux-objdump -t toolchain/build/mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/mips-linux-uclibc/lib/libpthread.a | grep ".* [gw] .* $sym"; done
000019cc  w    F .text  00000a30 pthread_create
00000000 g     F .text  000000c0 pthread_detach
00000074 g     F .text  000001c0 pthread_join
00000000 g     F .text  00000070 pthread_mutex_destroy
00000000 g     F .text  000001b0 pthread_mutex_init
000005f4 g     F .text  000002b8 pthread_mutex_lock
00000670 g     F .text  00000050 pthread_mutex_unlock
pi@pi4:/media/pi/extern_10_320/pi4/builds/grx5 $
... aber auch das sollte hier keine Rolle spielen für den Linker (zu "weak symbols" empfehle ich wieder die Suche im Netz).

EDIT3:
Wenn man das mit dem zusätzlichen "LIBDIR" noch einmal versuchen wollte, kann es auch nicht schaden, dessen Definition VOR den Versuch, darin eine Library zu finden, zu setzen ... also das "-L" vor das "-l" - falls der Linker hier doch sofort die Option versucht auszuwerten und das zusätzliche "LIBDIR" nur für später verwendete Bibliotheksdefinitionen Anwendung findet (das weiß ich aus dem Kopf nicht, ob dieses Verhalten - was es bei anderen Optionen durchaus gibt - jetzt auch für die LIBDIR-Definitionen gilt ... aber es steht garantiert auch irgendwo in der GCC-Doku).
 
Zuletzt bearbeitet:
Je öfter ich deine Beiträge lese, desto besser verstehe die Gründzuge deiner Aussagen. Danke dafür.

Also bleibt wohl doch nichts anderes, als da mal die Option "--verbose" den "EXTRA_LDFLAGS" ...
Rich (BBCode):
# Auszug von make/php/php.mk
...
ifeq ($(strip $(FREETZ_PACKAGE_PHP_STATIC)),y)
$(PKG)_EXTRA_LDFLAGS += -all-static -lpthread --verbose
endif
...
Wäre das so richtig?

zu EDIT und EDIT2:
Das konnte ich nachvollziehen und kam auf gleiche Ergebnisse bzw. Aussagen.

zu EDIT3:
Ich vestand dich so, dass ich die "php.mk" wie folgt abänderte:
Rich (BBCode):
# Auszug von make/php/php.mk
...
ifeq ($(strip $(FREETZ_PACKAGE_PHP_STATIC)),y)
$(PKG)_EXTRA_LDFLAGS += -L$(TARGET_TOOLCHAIN_STAGING_DIR)/lib
$(PKG)_EXTRA_LDFLAGS += -all-static -lpthread
endif
...
Jedoch erhielt ich wieder ein vertrautes "ERROR: Bulid failed".
 
Zuletzt bearbeitet:
Mist ... dann hast Du erst mal alles getestet, was mir in den Sinn kam, wobei die Ausgabe des letzten Laufs (wo dank des "--verbose" ja mehr zu sehen sein sollte) wohl noch fehlt. Ich muß jetzt für ca. 2 Stunden weg, danach werfe ich mal ein Build mit Deiner Konfiguration bei mir an - die Toolchain für GRX5-Boxen mit 07.12 ist ja schon fertig.

=======================================================================================

Bei der nächsten Gelegenheit solltest Du Dein Kennwort für den privaten Schlüssel, den Du zum Signieren von Images verwendest, ändern ... die oben stehende ".config" enthält dieses Kennwort.

Das ist eine Schwachstelle, die mir schon länger bewußt ist, zu deren Beseitigung ich aber bisher noch nichts unternommen habe (ist eigentlich auch "nicht mein Tisch", weil ich die Implementierung in Freetz nicht vorgenommen habe) - die beste Lösung ist und bleibt es eigentlich, dieses Kennwort gar nicht erst in der ".config" zu speichern, sondern in einer (versteckten, also mit einem Punkt am Beginn des Namens) Datei irgendwo in einem Verzeichnis, wo ausschließlich der verwendete Benutzer Zugriff hat, z.B. in seinem eigenen Home-Verzeichnis.

Ich muß mal sehen, ob ich sowohl diese Änderung als auch eine Art "Diagnose-Skript", was automatisch ein "fmake" anstelle des "make" verwendet und das Ergebnis dann - zusammen mit der komprimierten ".config", die dann auch kein Kennwort mehr enthält - in Form einer ZIP-Datei für den Upload bei einer Fehlermeldung bereitstellt, auf die Reihe kriege. Die einfachste Änderung, bei der in der ".config.compressed" (die erstellt man mit einem "make config-compress") das Kennwort entfernt wird (diese Datei ist dann quasi ein "Extrakt" aus den Einstellungen, wo nur noch die ggü. dem Standard geänderten Werte aufgeführt sind und man so auch viel besser sieht, was da geändert wurde), habe ich gleich mal als Pull-Request ausgeführt, damit ich das nicht wieder vergesse: https://github.com/Freetz/freetz/pull/283

====================================================================================

Ein Build mit Deiner Konfiguration läuft jetzt jedenfalls gerade auf meinem RasPi 4 und das dauert halt eine Weile - andere Rechner auf x86-Basis und mit mehr Power, arbeiten bei mir nicht mit Debian-basierten Systemen und damit ist der RasPi mit Raspbian immer noch das System, was der "Empfehlung" (also Ubuntu, afaik) am nächsten kommt.

Ich kann also noch nicht abschließend sagen, ob ich den Fehler reproduzieren kann - gestern habe ich das nicht mehr geschafft, weil aus zwei geplanten Stunden Abwesenheit deutlich mehr wurden.

====================================================================================

EDIT: Ich kann den Fehler bei mir nachstellen - jetzt kann es etwas dauern, bis ich die Ursache gefunden habe. Nach jeder Änderung an der "php.mk" geht der Build für PHP ja wieder von vorne los und das Paket ist etwas umfangreicher.

=======================================================================================

Ich hätte zumindest einen Workaround für Dich, mit dem Du die PHP-Binaries doch noch mit den gewählten Einstellungen erzeugen kannst.

Dazu müßtest Du in der Datei "toolchain/build/mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/mips-linux-uclibc/usr/lib/libcurl.la" die folgende Zeile stehen haben:
Rich (BBCode):
dependency_libs=' -L/media/pi/extern_10_320/pi4/builds/7590/toolchain/build/mips_gcc-5.5.0_uClibc-1.0.14-nptl_kernel-3.10/mips-linux-uclibc/usr/lib -lpthread -lssl -lcrypto -ldl'
Diese Datei wird aber erst erstellt, wenn das "curl"-Paket übersetzt wird ... das geht also erst nachdem das ohne Probleme durchlief und beim PHP der Fehler auftritt.

Die Einstellungen da drin übersteuern die Angaben für "libtool" auf der Kommandozeile für die "libcurl.a" und daher blieben die bisherigen Versuche auch erfolglos.

Wenn Du das beim ersten Auftreten des Fehlers beim PHP-Paket entsprechend anpaßt, sollte das Linken auch funktionieren, wenn Du das "make" noch einmal aufrufst.

Ich muß mich erst mal durch die ganzen Abhängigkeiten durchgraben, um die passende Stelle zu finden, wo diese zusätzliche Library hinzugefügt werden kann beim "make" für das "curl"-Paket und das dann möglichst auch noch so, daß es nur dann geändert wird, wenn eine "uClibc-ng" als C-Library verwendet wird.

Das kann nun auch wieder noch etwas dauern ... aber Du hättest ja erst einmal eine Lösung.

==========================================================================================

Bei der "box_info.cgi" ist die Änderung ja trivial. Kriegst Du das ggf. selbst hin? Die passende Quelle für die Info habe ich in #6 ja schon gezeigt und es reicht dann natürlich, wenn Du nur eine einzelne "cpu" ausliest und nur einen Wert anzeigst, weil die max. Taktfrequenz für alle dieselbe wäre - im Gegensatz zur aktuellen Frequenz, die unterschiedlich sein könnte. Den Teil mit dem "TFFS" kann man einfach komplett rauswerfen, eine 7590 hat gar keinen SPI-Flash.

EDIT: Langeweile ... daher hier noch ein Vorschlag für einen Patch der "box_info.cgi":
Code:
diff --git a/make/mod/files/root/usr/lib/cgi-bin/mod/box_info.cgi b/make/mod/files/root/usr/lib/cgi-bin/mod/box_info.cgi
index b3b521a07..76ae7ed52 100755
--- a/make/mod/files/root/usr/lib/cgi-bin/mod/box_info.cgi
+++ b/make/mod/files/root/usr/lib/cgi-bin/mod/box_info.cgi
@@ -48,8 +48,7 @@ if [ -r /proc/cpuinfo ]; then
        cpu_family=$(sed -ne '/system type/ s/.*: //p' /proc/cpuinfo | sed 's/Ikanos Fusiv.*/IKS/')
        cpu_model=$(sed -ne '/cpu model/ s/.*: //p' /proc/cpuinfo | head -n1)
        cpu_cores=$(grep $'^processor\t*:' /proc/cpuinfo | wc -l)
-       cpu_bogom="$(sed -ne '/BogoMIPS/ s/.*: //p' /proc/cpuinfo)"
-       cpu_bogom="$(echo $cpu_bogom | sed 's! ! / !g')"
+       cpu_bogom="$(sed -ne '/BogoMIPS/ s/.*: //p' /proc/cpuinfo | sed -ne "1p")"

else
        cpu_family=""
@@ -100,7 +99,6 @@ echo "</dl>"
if [ -n "$_CONFIG_NAND$_CONFIG_TFFS" ]; then
echo "<dl class='info'>"
echo "<dt>NAND</dt><dd>$_CONFIG_NAND MB</dd>"
-echo "<dt>TFFS</dt><dd>$_CONFIG_TFFS MB</dd>"
echo "</dl>"
fi

@@ -115,6 +113,8 @@ if [ -e /proc/clocks -o -e /proc/sys/urlader/environment ]; then
        echo "<dt>$(lang de:"Taktfrequenzen" en:"Clock frequencies")</dt><dl>"
        if [ -e /proc/clocks ]; then
                        sed 's/ [ ]*/ /g;s/^Clocks: //;s/^[A-Z0-9 ]*Clock: //;s/\([A-Za-z0-9]*\):[ ]*\([0-9,.]*\)[ ]*\([a-zA-Z]*\) */<dt>\1<\/dt><dd>\2 \3<\/dd>/g;' /proc/clocks 2>/dev/null
+       elif [ -e /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq ]; then
+               echo "<dt>CPU Cores $(cat /sys/devices/system/cpu/present)</dt><dd>$(( $(cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq) / 1000 )) MHz</dd>"
        else
                _CPU_FRQ="$(sed -n 's/^cpufrequency\t//p' /proc/sys/urlader/environment | awk '{ printf "%.0f", $1 /1000/1000 }')"
                _SYS_FRQ="$(sed -n 's/^sysfrequency\t//p' /proc/sys/urlader/environment | awk '{ printf "%.0f", $1 /1000/1000 }')"
Der funktioniert halt nur für GRX5-Boxen und wirft die TFFS-Angabe einfach raus.

Gleichzeitig wird für die gefundenen Cores die max. Taktfrequenz ausgegeben (und zwar auch nur auf volle MHz gerundet, weil ich keinen Bock hatte, das erst noch durch "awk" zu jagen, um da Kommastellen zu kriegen).

Die Angaben zu den "BogoMIPS" sind ohnehin Unfug, weil die von der aktuell eingestellten Taktfrequenz abhängen - da wird man also schwankende Werte sehen, je nach Auslastung der Box.

Alles in allem ist das auch eher ein "Notnagel" ... eine sinnvolle Anzeige von Hardware-Infos müßte sich eben auch auf die speziellen Eigenschaften der Hardware beziehen und nicht auf diesen "Käse", der in der Vergangenheit ja mal hilfreich gewesen sein mag, aber bei Stromsparmechanismen im SoC dann nur noch wenig aussagekräftig ist.
 
Zuletzt bearbeitet:
Hallo... Der Build läuft durch. Danke für Deine Hilfe.

Eine Frage am Rande: Was bedeutet der Einschub "-dirty" im Image-Name?
7590_07.12-freetz-master-20200407-1b5a9f88a-dirty.de_20200428-081729.image

Das mit der Box-Info ist mir momentan nicht so wichtig.
Na dann habe ich noch etwas... Wenn ich bei "Busybox Applets --> Editors --> [x] Awk" die Option
[*] Enable math functions (requires libm)
aktiviere, kommt es zu einem Fehler (siehe Anhang) mit einem Hinweis:
Code:
Note: if build needs additional libraries, put them in CONFIG_EXTRA_LDLIBS.
Wie packe ich das Benötigte (libm ?) in CONFIG_EXTRA_LDLIBS ?
 

Anhänge

  • fmake_2020-04-28_08-36-11.log.txt
    4.1 KB · Aufrufe: 2
dirty = eigene Änderungen an Dateien aus dem Checkout (git status)

Das mit der "libm" sehe ich mir später mal an.

EDIT:
Bei der BusyBox versucht man mit einem zusätzlichen Skript (scripts/trylink) die Größe des entstehenden Programms (zur Laufzeit, denn erst da werden dann die zusätzlichen DSOs (das sind die <something>.so-Files in den "lib"-Verzeichnisses) geladen und belegen dann Platz im Speicher und brauchen Zeit zum Laden) dadurch zu reduzieren, daß man nicht benötigte Bibliotheken nicht einbindet. Dabei beißen sich jetzt offenbar ein paar zusätzliche Änderungen hinsichtlich der Sichtbarkeit von Symbolen mit der neuen "uClibc-ng" (die wird ja noch nicht soo lange als C-Library verwendet, vorher war es die "uClibc") und bisher hat es wohl noch niemand bemerkt.

Daher scheitert das (zirkuläre) Suchen nach aufzulösenden Symbolen innerhalb der Grenzen der zu durchsuchenden Bibliotheken, die jeweils mit dem "--start-group" und "--end-group" gesetzt werden und es kommt in der "libcrypto.so" aus irgendeinem (bisher ungeklärten) Grund zu einem Widerspruch bei den Attributen eines gefundenen Symbols.

Die eigentliche Ursache findet man hier wohl auch erst wieder, wenn man sich das Erstellen der "libcrypt" und der "libm" noch einmal genauer ansieht bzw. das ausführlicher protokollieren läßt ... das erfolgt dann im Rahmen des Erstellens der Toolchain und ist eine der zeitaufwändigsten Aktionen bei so einem Freetz-Build (für die uClibc-ng gibt es m.W. auch noch keine Download-Toolchain vom originalen Freetz-Projekt).

Als Workaround würde ich (nur als Idee) mal versuchen, die BusyBox ohne das "trylink" zu linken - iirc gibt es da irgendwo auch eine Option, ob diese Tests mit dem Ziel, das Binary mit so wenig "footprint" wie möglich auszustatten, ausgeführt werden sollen oder nicht. Im Moment weiß ich aber nicht, wo die exakt zu finden wäre und wie sie heißt - und schon gar nicht, ob das Linken am Ende klappen wird, wenn die rekursive Auflösung von Symbolen nicht auf die beiden Bibliotheken (libcrypt und libm) beschränkt wird - ich rate einfach mal, daß da ein Symbol aus der "eigentlichen" Bibliothek "libc" (bzw. libuClibc-ng.so.irgendwas) das Problem bereits beheben könnte, was aber hier durch die "--start-group" und "--end-group" verhindert wird beim Aufruf des "ld".

Das nur als "Zwischenstand" ... dauert also noch bei mir.
 
Zuletzt bearbeitet:
Lass dir ruhig etwas Zeit... ( in der Zwischenzeit suche ich weiter nach Ungereimtheiten ;) )
 
Meinetwegen muß das auch nicht sein mit der Suche nach weiteren Problemen ... ich bin eigentlich eher "Beobachter", wenn's um irgendwelche Dinge jenseits der Toolchain und der von mir tatsächlich selbst benötigten Pakete geht (wobei hier die von mir bereitgestellten Binaries enthalten sind in diesen "Interessen").
 

Neueste Beiträge

Statistik des Forums

Themen
244,691
Beiträge
2,216,608
Mitglieder
371,308
Neuestes Mitglied
Chrischan 79
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.