fischertechnik community forum

Verfasst: **27 Feb 2017, 14:58**

Hallo,

make meldet irgendwann:

(Versuch: 3) http://ftp.dlitz.net/pub/dlitz/crypto/p ... 6.1.tar.gz
Verbindungsaufbau zu ftp.dlitz.net (ftp.dlitz.net)|2600:31:7099|:80... fehlgeschlagen: Die Wartezeit für die Verbindung ist abgelaufen.

Was passiert da? Da hängt's jetzt...

Gruß
Peter

Verfasst: **27 Feb 2017, 15:16**

Entweder warten bis der Server wieder verfügbar ist oder einfach nach der Datei googlen, sie ins dl-Verzechnis legen und make nochmal starten.

Verfasst: **27 Feb 2017, 16:10**

Danke....

Jetzt failts hier:

CXXLD lib/evas/libevas.la
CCLD lib/efreet/libefreet.la
ELUA lib/ecore_con/ecore_con_base.eo.lua
ELUA lib/ecore_con/ecore_con_client.eo.lua
ELUA lib/ecore_con/ecore_con_server.eo.lua
ERR<14145>:elua lib/elua/elua.c:647 _elua_errmsg() ../src/bin/elua/elua: ...t/build/host-efl-1.17.2/src/bindings/luajit/eina/log.lua:53: libeina.so: Kann die Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden
stack traceback:
[C]: in function 'error'
...put/build/host-efl-1.17.2/src/scripts/elua/core/util.lua:162: in function 'lib_load'
...t/build/host-efl-1.17.2/src/bindings/luajit/eina/log.lua:53: in function <...t/build/host-efl-1.17.2/src/bindings/luajit/eina/log.lua:52>
[C]: in function 'init_module'
...t/build/host-efl-1.17.2/src/bindings/luajit/eina/log.lua:63: in function 'loader'
...t/build/host-efl-1.17.2/src/scripts/elua/core/module.lua:94: in function 'require'
...ild/host-efl-1.17.2/src/scripts/elua/modules/lualian.lua:5: in function 'loader'
...t/build/host-efl-1.17.2/src/scripts/elua/core/module.lua:94: in function 'require'
.../build/host-efl-1.17.2/src/scripts/elua/apps/lualian.lua:4: in main chunk
[C]: at 0x00401540
ERR<14146>:elua lib/elua/elua.c:647 _elua_errmsg() ../src/bin/elua/elua: ...t/build/host-efl-1.17.2/src/bindings/luajit/eina/log.lua:53: libeina.so: Kann die Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden
stack traceback:
[C]: in function 'error'
...put/build/host-efl-1.17.2/src/scripts/elua/core/util.lua:162: in function 'lib_load'
...t/build/host-efl-1.17.2/src/bindings/luajit/eina/log.lua:53: in function <...t/build/host-efl-1.17.2/src/bindings/luajit/eina/log.lua:52>
[C]: in function 'init_module'
...t/build/host-efl-1.17.2/src/bindings/luajit/eina/log.lua:63: in function 'loader'
...t/build/host-efl-1.17.2/src/scripts/elua/core/module.lua:94: in function 'require'
...ild/host-efl-1.17.2/src/scripts/elua/modules/lualian.lua:5: in function 'loader'
...t/build/host-efl-1.17.2/src/scripts/elua/core/module.lua:94: in function 'require'
.../build/host-efl-1.17.2/src/scripts/elua/apps/lualian.lua:4: in main chunk
[C]: at 0x00401540
Makefile:40671: recipe for target 'lib/ecore_con/ecore_con_base.eo.lua' failed
make[5]: *** [lib/ecore_con/ecore_con_base.eo.lua] Error 1
make[5]: *** Warte auf noch nicht beendete Prozesse...
Makefile:40671: recipe for target 'lib/ecore_con/ecore_con_client.eo.lua' failed
make[5]: *** [lib/ecore_con/ecore_con_client.eo.lua] Error 1
ERR<14148>:elua lib/elua/elua.c:647 _elua_errmsg() ../src/bin/elua/elua: ...t/build/host-efl-1.17.2/src/bindings/luajit/eina/log.lua:53: libeina.so: Kann die Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden
stack traceback:
[C]: in function 'error'
...put/build/host-efl-1.17.2/src/scripts/elua/core/util.lua:162: in function 'lib_load'
...t/build/host-efl-1.17.2/src/bindings/luajit/eina/log.lua:53: in function <...t/build/host-efl-1.17.2/src/bindings/luajit/eina/log.lua:52>
[C]: in function 'init_module'
...t/build/host-efl-1.17.2/src/bindings/luajit/eina/log.lua:63: in function 'loader'
...t/build/host-efl-1.17.2/src/scripts/elua/core/module.lua:94: in function 'require'
...ild/host-efl-1.17.2/src/scripts/elua/modules/lualian.lua:5: in function 'loader'
...t/build/host-efl-1.17.2/src/scripts/elua/core/module.lua:94: in function 'require'
.../build/host-efl-1.17.2/src/scripts/elua/apps/lualian.lua:4: in main chunk
[C]: at 0x00401540
Makefile:40671: recipe for target 'lib/ecore_con/ecore_con_server.eo.lua' failed
make[5]: *** [lib/ecore_con/ecore_con_server.eo.lua] Error 1
Makefile recipe for target 'all-recursive' failed
make[4]: *** [all-recursive] Error 1
Makefile recipe for target 'all' failed
make[3]: *** [all] Error 2
Makefile recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
Makefile recipe for target 'all' failed
make[1]: *** [all] Error 2

Verfasst: **28 Feb 2017, 18:20**

Hallo Peter,

läuft der Build wieder?

Ansonsten: Die Fehlermeldung sieht so aus, als wäre der EFL-Build nur unvollständig durchgelaufen (die in der Fehlemeldung fehlende libeina.so gehört da auch zu). Lösch mal output/build/host-efl-1.17.2/ und output/build/efl-1.17.2/ und schau ob es dann klappt.

Alternativ: "make clean; make" (und dann gemütlich Essen und ins Kino gehen

)

Verfasst: **28 Feb 2017, 18:39**

Hallo Richard,

nein, bis jetzt ist der build nicht durchgelaufen.

Weitere Info: mein System ist Suse 42.2 64-bit

Ich habe aus lauter Ideenlosigkeit mit dem Suse-Paketmanager dass EFI-Devel-Paket nachinstalliert und den Build neugestartet (also make clean/make).
Es wurden dann zwei weitere Elua-libs gebaut, bei der dritten folgenden blieb der Rechner eine Stunde lang mit 100%CPU-Load hängen, dann bin ich auf Dienstreise gegangen...
Ich werde nachher mal über meine Frau Rückmeldung einholen, ob sich etwas getan hat. Ansonsten kann ich ab Donnerstag Abend weiterprobieren.

Da das nachinstallieren der EFI-Sources unter Suse eine wahrnehmbare Änderung brachte, vermute ich, daß die benötigten Sourcen dem buildsystem nicht zur Verfügung stehen. Ich vermute weiters, daß das Einbinden der SUSE-Sourcen in die CFW Probleme bringen könnte...

Was denkst Du?

Gruß
Peter

Verfasst: **28 Feb 2017, 18:41**

Ich baue die letzten Wochen immer auf Ubuntu und habe da keine Probleme.

Raphael

Verfasst: **28 Feb 2017, 18:43**

Hallo Raphael,

dann scheint das an der Stelle noch ein bisschen Glückssache zu sein....

Hast Du unter Ubuntu die EFI-Sourcen installiert? Sind die bei einer Standardinstallation dabei oder hast Du die selbst irgendwann nachinstalliert?

Gruß
Peter

Verfasst: **28 Feb 2017, 18:46**

Keine Ahnung, aber außer mal mit ein paar Problemen mit fehlen python libs hatte ich keine Probleme

Verfasst: **28 Feb 2017, 20:37**

PHabermehl hat geschrieben: nein, bis jetzt ist der build nicht durchgelaufen.

Schade.

PHabermehl hat geschrieben: Weitere Info: mein System ist Suse 42.2 64-bit

Ich habe aus lauter Ideenlosigkeit mit dem Suse-Paketmanager dass EFI-Devel-Paket nachinstalliert und den Build neugestartet (also make clean/make).
Es wurden dann zwei weitere Elua-libs gebaut, bei der dritten folgenden blieb der Rechner eine Stunde lang mit 100%CPU-Load hängen, dann bin ich auf Dienstreise gegangen...
Ich werde nachher mal über meine Frau Rückmeldung einholen, ob sich etwas getan hat. Ansonsten kann ich ab Donnerstag Abend weiterprobieren.

Ist "EFI" ein Tippfehler hier im Post? Falls nein: Dann haben irgendwelche EFI-Includes bestimmt keinen Einfluss auf das Problem - das klemmt nämlich bei EFL (den "Enlightenment Foundation Libraries") und nicht beim "Extensible Firmware Interface"

Ansonsten: Wenn das make clean/make allein nichts geholfen hat stimmt da wohl was nicht. Header/Libraries für irgendwelche Pakte sollte man auf dem Host eigentlich überhaupt nicht nachinstallieren müssen, da kümmert sich Buildroot eigentlich selbst drum

Allerdings hakt es genau dabei durchaus schon mal, und es kann passieren dass auf dem Buildhost installierte Software da beim Bauen "dazwischengrätscht", weil das Buildsystem die global installierte Version verwendet statt der speziellen aus output/host/... . Wenn ich mich richtig erinnere hatte ich mal ein ähnliches Problem - allerdings mit Python und nicht mit LUA, und das war glaube ich bei einem Paket, das ich neu aufgenommen hatte.

Von daher würde ich mal in die Richtung weitersuchen:

Hast Du auf dem System schon mal die CFW erfolgreich gebaut?
Falls ja: Hast Du vor dem ersten fehlgeschlagenen Build irgendwelche Software nachinstalliert? Insbesondere natürlich EFL (oder irgendwas was die braucht)?
Falls nein: Hattest Du schon beim ersten Build EFL installiert (bzw. kommt SuSE per Default damit)?
und generell: Schau mal in die Ausgaben, die der Build macht (insbesondere auch die von "configure" in den entsprechenden Paketen) ob da irgendwo Systempfade verwendet werden statt welchen unter output/host, output/statging oder output/build.

PHabermehl hat geschrieben: Da das nachinstallieren der EFI-Sources unter Suse eine wahrnehmbare Änderung brachte, vermute ich, daß die benötigten Sourcen dem buildsystem nicht zur Verfügung stehen.

Ich vermute eher, dass da bei Dir irgendwas bei den Build-Pfaden durcheinanderkommt.

EFL ist schon seit ewig mit im Build dabei (seit commit ff4f5d97343ce14453d90ce5c6958aaf15e466f5 am 21.2.2016) - wenn da generell irgendwelche notwendigen Dinge nicht mit dabei wären, dann wäre das schon vorher mal aufgefallen (z.B. bei mir - ich hab auf meinem [Debian-] System ganz definitiv kein EFL installiert, und ebenso definitiv im letzten Jahr auch schon ein paar mal erfolgreich die CFW gebaut

)

Verfasst: **28 Feb 2017, 20:46**

Hallo Richard,

danke für die Antwort, EFI soll natürlich EFL heißen, das hab ich jetzt "aus der Ferne" durcheinandergeworfen.

Ich habe die fw noch nie gebaut. Bei den ersten Versuchen waren die EFL-Sources nicht installiert, wie gesagt, das habe ich dann aus Verzweiflung versucht, und dann ging es zumindest "etwas" weiter...

Ok, werde dann am Donnerstag/Freitag mal in der Richtung weitersuchen...

Gruß
Peter

Verfasst: **28 Feb 2017, 20:57**

PHabermehl hat geschrieben: Ich habe die fw noch nie gebaut. Bei den ersten Versuchen waren die EFL-Sources nicht installiert, wie gesagt, das habe ich dann aus Verzweiflung versucht, und dann ging es zumindest "etwas" weiter...

OK, das geht dann wohl in die Richtung dass da irgendwas zwischen SuSE und Buildroot klemmt (und wieder mal ein Argument für eine neues Buildsystem - eigentlich sollte sowas nämlich nicht passieren...). Kommt SuSE eventuell per Default mit https://www.enlightenment.org/ (oder hast Du das bei Dir nachinstalliert)?

Verfasst: **28 Feb 2017, 21:05**

Nö, ich habe KDE, enlightenment war nicht installiert, hab die sources dann installiert, weil ja die fehlende lib da aus dem Umfeld kam....

Ärks,

sagt mal, ich habe gerade gesehen, da wird einiges für x86_64 gebaut... Jede Menge Pakete, deren Namen mit host- beginnt. Tut das Not? Das fragliche EFL-Paket, daß bei mir nicht gebaut wird, ist auch für x86_64... Auch auf einem 2. Suse-Rechner (mit Suse 13.2) genau gleiches Verhalten, nach Installation der EFL-Sources läuft der build etwas weiter, es kommt noch

CCLD lib/ecore_evas/libecore_evas.la
ELUA lib/ecore_con/ecore_con_client.eo.lua
ELUA lib/ecore_con/ecore_con_base.eo.lua
ELUA lib/ecore_con/efl_network_connector.eo.lua
ELUA lib/ecore_con/ecore_con_server.eo.lua
ELUA lib/ecore_con/ecore_con_eet_base.eo.lua

d.h., offensichtlich passiert da was, aber bei der letzten Zeile ist einfach Schluß, 100%CPU-Load, es kommt nix mehr, stundenlang....
Jemand ne Idee?

Gruß
Peter

Also die host- Pakete sind unbedingt notwendig. Das sind Pakete, die dein TXT nicht braucht, jedoch für den Build-Vorgang erforderlich sind.

Raphael

Ah, okay, danke.

MIST...

also, das witzige ist, daß bei

Code: Alles auswählen

  CCLD     bin/efreet/efreet_icon_cache_create
  ELUA     lib/ecore_con/ecore_con_base.eo.lua
  CCLD     bin/evas/evas_cserve2
ERR<8733>:elua lib/elua/elua.c:647 _elua_errmsg() ../src/bin/elua/elua: ...t/build/host-efl-1.17.2/src/bindings/luajit/eina/log.lua:53: libeina.so: Kann die Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden
stack traceback:
        [C]: in function 'error'
        ...put/build/host-efl-1.17.2/src/scripts/elua/core/util.lua:162: in function 'lib_load'
        ...t/build/host-efl-1.17.2/src/bindings/luajit/eina/log.lua:53: in function <...t/build/host-efl-1.17.2/src/bindings/luajit/eina/log.lua:52>
        [C]: in function 'init_module'

die libeina.so sehr wohl vorher gebaut wurde, die findet man... Offensichtlich stimmt also etwas mit den Pfaden nicht, weil ja auf die Dateien des Build-Systems, nicht aber auf die gerade gebauten Dateien, zugegriffen wird...
Aber wo muß ich da schauen, wo stehen die Pfade drin???

Hallo Peter,

PHabermehl hat geschrieben: also, das witzige ist, daß bei (...) die libeina.so sehr wohl vorher gebaut wurde, die findet man... Offensichtlich stimmt also etwas mit den Pfaden nicht, weil ja auf die Dateien des Build-Systems, nicht aber auf die gerade gebauten Dateien, zugegriffen wird...
Aber wo muß ich da schauen, wo stehen die Pfade drin???

Fang mal mit output/build/host-efl-1.17.2/config.log und output/build/efl-1.17.2/config.log an. Und schau Dir da vor allem mal alles an, was mit "elua" zu tun hat - da scheint es der Fehlermeldung nach ja zu klemmen. Generell sollten die Pfade in config.log auch wieder in die Buildumgebung zeigen und nicht irgendwo außerhalb ins System (da gibt es aber auch Ausnahmen, die Angaben unter "PATH" am Anfang des Logs dürfen durchaus auch Systempfade enthalten).

Wenn Du so nicht weiterkommst, kann ich Dir zum Vergleich auch mal meine Config-Logs schicken - als Attachment hier geht aber leider nicht (die Forensoftware mag so wie es aussieht keine Textfiles als Attachment), und zum hier reinpasten sind sie etwas zu groß (jeweils gut 400 KByte).

Ich hab den EFL-Build (Host und Target) übrigens bei mir gerade auch mal neu durchlaufen lassen - ist sauber durchgelaufen und hat dafür etwa 10 Minuten gebraucht (auf einem etwas älteren Laptop mit Intel Core2Duo@2.4 Ghz und 4 GB RAM).

ich hab jetzt mal in
...put/build/host-efl-1.17.2/src/scripts/elua/core/util.lua:165
geschaut und die drei *-Zeilen eingefügt:

Code: Alles auswählen

        local ev = os.getenv("ELUA_" .. libname:upper() .. "_LIBRARY_PATH")
*       print("*******************************PETERDEBUG*************************************")
*       print("ELUA_" .. libname:upper() .. "_LIBRARY_PATH")
*       print(ev)        
165:  local succ, v = load_lib(libname, ev)

Im Output des Build steht dann:

Code: Alles auswählen

  CCLD     bin/ecore_evas/eetpack
  ELUA     lib/ecore_con/ecore_con_base.eo.lua
*******************************PETERDEBUG*************************************
ELUA_EINA_LIBRARY_PATH
nil
ERR<9768>:elua lib/elua/elua.c:647 _elua_errmsg() ../src/bin/elua/elua: ...t/build/host-efl-1.17.2/src/bindings/luajit/eina/log.lua:53: libeina.so: Kann die Shared-Object-Datei nicht öff

Daraus schließe ich, daß die Umgebungsvariable ELUA_EINA_LIBRARY_PATH nicht gesetzt wurde...

Nur. .. Warum?

Next step...

ich habe die variable per

Code: Alles auswählen

 export ELUA_EINA_LIBRARY_PATH=....ftcommunity-TXT/output/build/host-efl-1.17.2/src/lib/eina/.libs/

auf den von mir vorher ermittelten Pfad gesetzt.

uuuuuuunnd.... der Build läuft weiter.........

Gnarf...

PHabermehl hat geschrieben:ich hab jetzt mal in
...put/build/host-efl-1.17.2/src/scripts/elua/core/util.lua:165
geschaut und die drei *-Zeilen eingefügt:
Code: Alles auswählen
        local ev = os.getenv("ELUA_" .. libname:upper() .. "_LIBRARY_PATH")
*       print("*******************************PETERDEBUG*************************************")
*       print("ELUA_" .. libname:upper() .. "_LIBRARY_PATH")
*       print(ev)        
165:  local succ, v = load_lib(libname, ev)
Im Output des Build steht dann:
Code: Alles auswählen
  CCLD     bin/ecore_evas/eetpack
  ELUA     lib/ecore_con/ecore_con_base.eo.lua
*******************************PETERDEBUG*************************************
ELUA_EINA_LIBRARY_PATH
nil
ERR<9768>:elua lib/elua/elua.c:647 _elua_errmsg() ../src/bin/elua/elua: ...t/build/host-efl-1.17.2/src/bindings/luajit/eina/log.lua:53: libeina.so: Kann die Shared-Object-Datei nicht öff
Daraus schließe ich, daß die Umgebungsvariable ELUA_EINA_LIBRARY_PATH nicht gesetzt wurde...

Nur. .. Warum?

Weiss ich auch nicht - und ich weiß auch nicht, ob das relevant ist.

Welcher Build ist das denn eigentlich? Noch der von host-efl, oder schon der für das Target?

Und was sagt kommt denn bei Dir bei

Code: Alles auswählen

file -L output/build/*efl*/src/lib/eina/.libs/libeina.so

raus? Bei mir ist das

Code: Alles auswählen

output/build/efl-1.17.2/src/lib/eina/.libs/libeina.so:      ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=ac8242435fa5d7be5e914465531fb11ca0c77724, not stripped
output/build/host-efl-1.17.2/src/lib/eina/.libs/libeina.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=d92c31ae9ca7f0d414d60b0c94b008543977e3e4, not stripped

Und ansonsten: Schau mal in den Config-Logs nach "eina", ob da irgendwas verdächtig ist.

PHabermehl hat geschrieben:Next step...

ich habe die variable per
Code: Alles auswählen
 export ELUA_EINA_LIBRARY_PATH=....ftcommunity-TXT/output/build/host-efl-1.17.2/src/lib/eina/.libs/
auf den von mir vorher ermittelten Pfad gesetzt.

uuuuuuunnd.... der Build läuft weiter.........

Gnarf...

Schön dass der Build weiterläuft. Allerdings sollte das eigentlich nicht nötig sein (und bei mir ist es auch nicht nötig).

Kannst Du trotzdem mal nachschauen was zu "eina" und "elua" in den beiden config.log-Dateien steht und das hier reinpasten?

fischertechnik community forum

Problem beim CFW-Build

Problem beim CFW-Build

Re: Problem beim CFW-Build

Re: Problem beim CFW-Build

Re: Problem beim CFW-Build

Re: Problem beim CFW-Build

Re: Problem beim CFW-Build

Re: Problem beim CFW-Build

Re: Problem beim CFW-Build

Re: Problem beim CFW-Build

Re: Problem beim CFW-Build

Re: Problem beim CFW-Build

Re: Problem beim CFW-Build

Re: Problem beim CFW-Build

Re: Problem beim CFW-Build

Re: Problem beim CFW-Build

Re: Problem beim CFW-Build

Re: Problem beim CFW-Build

Re: Problem beim CFW-Build

Re: Problem beim CFW-Build

Re: Problem beim CFW-Build