python auf einer non-freetz 7590

rolex0815

Mitglied
Mitglied seit
28 Jan 2011
Beiträge
206
Punkte für Reaktionen
5
Punkte
18
Ich fand nur 2 sehr alte Threads über dieses Thema.

Habe mit freetz-ng ein python package erstellt: make python-precompiled
Scheitern tut es beim Ausführen auf der Box und mit der Meldung steh ich im Regen.

Rich (BBCode):
# mount
/dev/sda1 on /var/media/ftp/16_GB type ext4 (rw,relatime,data=ordered)

# pwd
/var/media/ftp/16_GB/python

# ls -l
drwxrwxrwx    2 root     root          4096 Feb 26 14:21 bin
drwxrwxrwx    3 root     root          4096 Feb 26 14:21 include
drwxrwxrwx    4 root     root          4096 Feb 26 14:21 lib

# cd bin/

# ls -l
lrwxrwxrwx    1 root     root             7 Feb 26 14:21 python -> python2
lrwxrwxrwx    1 root     root             9 Feb 26 14:21 python2 -> python2.7
-rwxrw-rw-    1 root     root           431 Mar  2 23:12 python2.7
-rwxrwxrwx    1 root     root       1521628 Feb 26 14:21 python2.7.bin

# cat python
#!/bin/sh

# Change the value of PYTHONHOME variable and comment LD_LIBRARY_PATH line in
# if you want to use python on an unmodified box. Don't forget to copy all
# libraries python and its modules depend on to ${PYTHONHOME}/lib/freetz.

set -x

export PYTHONHOME="/var/media/ftp/16_GB/python"
export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}${LD_LIBRARY_PATH:+:}${PYTHONHOME}/lib/freetz"
exec "${PYTHONHOME}/bin/python2.7.bin" -B "$@"

# ./python --version
+ export 'PYTHONHOME=/var/media/ftp/16_GB/python'
+ export 'LD_LIBRARY_PATH=/var/media/ftp/16_GB/python/lib/freetz'
+ exec /var/media/ftp/16_GB/python/bin/python2.7.bin -B --version
./python: exec: line 11: /var/media/ftp/16_GB/python/bin/python2.7.bin: not found
Das set -x hab ich eingefügt. Die Libraries sind im entsprechenden Ordner ${PYTHONHOME}/lib/freetz.
Es scheint überhaupt nicht versucht zu werden, den Interpreter zu starten.

Braucht's doch ein freetz environment?
 
Zuletzt bearbeitet:
Ein "not found" kann tatsächlich auch dann auftreten, wenn eine Bibliothek durch den dynamischen Loader nicht gefunden wird.

Baue Dir mal mit der Freetz-Toolchain (ich hoffe, daß es mit der in NG noch funktioniert) die Build-Tools für das Target-Device - da ist dann auch ein ldd dabei, mit dem Du - eine Zeile über dem Python-Aufruf, damit das Environment dasselbe ist - leicht prüfen kannst, welche Libraries da nachgeladen werden sollen und wo/wie die gefunden werden können ... einfach das Binary zusätzlich kopieren. Die von diesem selbst wieder benötigten Libraries (libc.so + ld-uClibc.so, wenn mit einer uClibc-ng gebaut) braucht's dann natürlich auch noch - die sollten aber ohnehin vorhanden sein und ich vermute eher (reiner Instinkt, keine Fakten, die das erklären würden), daß da irgendeine andere Library noch vom Python-Interpreter gebraucht wird, die Du nicht mit kopiert hast auf Deinen Stick.
 
Danke wieder mal für die Infos - much appreciated!

Die Target-Toolchain krieg ich nicht kompiliert. Identischer Fehler wie in diesem Thread ohne wirkliche Lösung: https://www.ip-phone-forum.de/threads/freetz-ng-fehler-beim-bauen-für-unterschiedliche-konfigurationen.308030/
Die Lösung für den TE war leider nur die Option abzuwählen. :(
Dir ist es in diesem Thread gleich ergangen: https://www.ip-phone-forum.de/threads/freetz-ng-fehler-beim-bauen-für-unterschiedliche-konfigurationen.308030/post-2387942
Ich versuch es noch mit dem "normalen" freetz - ich zweifle allerdings, ob sich die Versionen nicht schon zu sehr unterscheiden (freetz <--> FritzOS 7.25).
 
Trotzdem kannst Du dann ja mit dem (MIPS-)ldd aus dem toolchain-Verzeichnis einfach mal die benötigten Libraries anzeigen lassen, dann mußt Du halt auf die Anzeige der passenden Dateien auf der Box verzichten und das von Hand selbst prüfen, ob die auch auf der Box gefunden werden können.

EDIT: Ich meine da natürlich das ldd, das selbst ein Binary für den Build-Host ist, aber sich auch mit MIPS-Binaries auskennt.
 
Schon gemacht, die angezeigten Libraries sind alle vorhanden auf der Box. Ich habe auch schon durchvariiert, ob es lib/freetz oder nur lib/ sein muss, habe auch das komplette /usr/lib/freetz/ Verzeichnis im freetz-ng Ordner für die Box dereferenziert mittels cp -L also die symlinks in "echte" Dateien gewandelt.

Rich (BBCode):
$ mips-linux-ldd python2.7.bin
checking sub-depends for 'not found'
checking sub-depends for 'not found'
    libz.so.1 => not found (0x00000000)
    libc.so.0 => not found (0x00000000)
    /usr/lib/freetz/ld-uClibc.so.1 => /usr/lib/freetz/ld-uClibc.so.1 (0x00000000)
 
Dann rücke dem Binary doch mal mit readelf zu Leibe ... zu prüfen wäre u.a. auch noch die Zielarchitektur (das sollte MIPS32) und da sollte man dann auch die Libraries genau sehen. Ich bin nämlich (ohne zu wissen oder nachzusehen, wie Python in Freetz genau gebaut wird) etwas überrascht - üblicherweise ist das Binary nur ein CLI.-Wrapper für irgendeine libpython, die dann den eigentlichen Python-Core enthält ... jedenfalls wenn man Python mit "shared library" baut.

Ist denn das Binary tatsächlich groß genug, daß das die libpython statisch enthalten kann? Oder haben die beiden checking sub-depends for 'not found' am Ende doch eine tiefere Bedeutung (ich weiß es auch nicht und müßte erst in den Quellen nachsehen, wann diese Nachricht überhaupt erzeugt wird) und es sind zwei Zeilen für Libraries, die halt auf dem Build-System nicht gefunden/falsch gesucht werden?

Denn bei den angezeigten Library-Namen oben würde ich vermuten, daß diese Zeilen das Resultat einer zwar gefundenen Library, die aber nicht das richtige Format hat, sind ... denn eigentlich sollte der Build-Host irgendwo eine libz.so.1 haben (vermutlich in /usr/lib - die kannst Du ja auch mal mit find versuchen zu finden) und da kann das angezeigte not found eigentlich nur noch daher kommen, daß da die Architektur der Library nicht zum Binary paßt.
 
Ob die Probleme wegen der geänderten C-Bibliothek kommen? Ich meine den Wechsel zu musl statt uClibc.
---
Wie schon geschrieben, eine target-toolchain lässt sich mit freetz-ng zur Zeit nicht erstellen.
Mit dem klassischen freetz funktioniert es, aber die erstellten binaries im Ordner target-utils laufen auf der 7590 mit 7.25 nicht ("not found").
Environment wurde analog zu https://www.ip-phone-forum.de/threa...ieren-eigener-c-programme.270200/post-2341981 gesetzt.
---
Python wurde statisch kompiliert, das hätte ich schon schreiben sollen.
Die readelf Attacke ergab (gekürzt um das hoffentlich Unwesentliche):

Rich (BBCode):
$ readelf -a python2.7.bin
ELF-Header:
  Magic:   7f 45 4c 46 01 02 01 00 01 00 00 00 00 00 00 00
  Klasse:                            ELF32
  Daten:                             2er-Komplement, Big-Endian
  Version:                           1 (aktuell)
  OS/ABI:                            UNIX - System V
  ABI-Version:                       1
  Typ:                               EXEC (ausführbare Datei)
  Maschine:                          MIPS R3000
  Version:                           0x1
  Einstiegspunktadresse:               0x40fc10
  Beginn der Programm-Header:          52 (Bytes in Datei)
  Beginn der Sektions-header:          1520428 (Bytes in Datei)
  Flags:                             0x70001005, noreorder, cpic, o32, mips32r2
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         10
  Size of section headers:           40 (bytes)
  Number of section headers:         30
  Section header string table index: 29

Programm-Header:
  Typ            Offset   VirtAdr    PhysAdr    DateiGr SpeiGr  Flg Ausr.
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x10
  NULL           0x000000 0x00000000 0x00000000 0x00000 0x00000     0x4
  LOAD           0x000000 0x003ff000 0x003ff000 0x00193 0x00193 RW  0x1000
  PHDR           0x000034 0x003ff034 0x003ff034 0x00140 0x00140 R   0x4
  INTERP         0x000174 0x003ff174 0x003ff174 0x0001f 0x0001f R   0x1
      [Requesting program interpreter: /usr/lib/freetz/ld-uClibc.so.1]
  LOAD           0x001000 0x00400000 0x00400000 0x147c50 0x147c50 R E 0x1000
  ABIFLAGS       0x001168 0x00400168 0x00400168 0x00018 0x00018 R   0x8
  REGINFO        0x001180 0x00400180 0x00400180 0x00018 0x00018 R   0x4
  DYNAMIC        0x001198 0x00400198 0x00400198 0x00128 0x00128 R   0x4
  LOAD           0x149000 0x00558000 0x00558000 0x2a224 0x3c8c0 RW  0x1000


Dynamic section at offset 0x1198 contains 32 entries:
  Tag       Typ                          Name/Wert
 0x00000001 (NEEDED)                     Gemeinsame Bibliothek [libz.so.1]
 0x00000001 (NEEDED)                     Gemeinsame Bibliothek [libc.so.0]
 0x0000000f (RPATH)                      Bibliothek rpath: [/usr/lib/freetz]
 0x0000000c (INIT)                       0x40fb90
 0x0000000d (FINI)                       0x51e730
 0x00000004 (HASH)                       0x4002c0
 0x00000005 (STRTAB)                     0x4085e4
 0x00000006 (SYMTAB)                     0x4029e4
 0x0000000a (STRSZ)                      25212 (Bytes)
 0x0000000b (SYMENT)                     16 (Bytes)
 0x70000016 (MIPS_RLD_MAP)               0x582200
 0x70000035 (MIPS_RLD_MAP_REL)           0x182010
 0x00000015 (DEBUG)                      0x0
 0x00000003 (PLTGOT)                     0x582210
 0x00000011 (REL)                        0x40f400
 0x00000012 (RELSZ)                      40 (Bytes)
 0x00000013 (RELENT)                     8 (Bytes)
 0x70000001 (MIPS_RLD_VERSION)           1
 0x70000005 (MIPS_FLAGS)                 NOTPOT
 0x70000006 (MIPS_BASE_ADDRESS)          0x400000
 0x7000000a (MIPS_LOCAL_GOTNO)           4
 0x70000011 (MIPS_SYMTABNO)              1472
 0x70000012 (MIPS_UNREFEXTNO)            39
 0x70000013 (MIPS_GOTSYM)                0x5c0
 0x00000014 (PLTREL)                     REL
 0x00000017 (JMPREL)                     0x40f428
 0x00000002 (PLTRELSZ)                   1896 (Bytes)
 0x70000032 (MIPS_PLTGOT)                0x558010
 0x6ffffffe (VERNEED)                    0x40f3e0
 0x6fffffff (VERNEEDNUM)                 1
 0x6ffffff0 (VERSYM)                     0x40e860
 0x00000000 (NULL)                       0x0
Es stellt sich die Frage, ob bei dieser Zeile [Requesting program interpreter: /usr/lib/freetz/ld-uClibc.so.1] der Pfad genau so sein muss. Das würde mMn aber dem Kommentar im Wrapper (erster Post) widersprechen.
 
Da wird er wohl tatsächlich mit absolutem Pfad nach dem Loader suchen ... das kannst Du ja leicht prüfen, indem Du mittels mount -o bind ... mal die passende Library an der richtigen Stelle "einblendest". Wobei ich auch die RPATH-Angabe im Python-Binary nicht verstehe ... ich dachte, ich hätte irgendwo gelesen, daß Du die entsprechend angepaßt hast beim Build (oder es war doch jemand anderes, dann solltest Du das aber auch machen).

Das würde mMn aber dem Kommentar im Wrapper (erster Post) widersprechen.
Der dürfte aber auch aus einer Zeit stammen, wo AVM und Freetz dieselbe C-Library verwendeten - das ist ja nicht mehr der Fall, wie Du selbst feststellst.



EDIT: Bei der RPATH-Frage hatte ich das hier: https://github.com/Freetz-NG/freetz-ng/discussions/189 im Kopf.
 
Zuletzt bearbeitet:
Spoiler: Ich krieg's noch immer nicht hin.

Den FREETZ_RPATH konnte ich ändern, das steht jetzt auf Bibliothek rpath: [/var/lib/freetz]
Da leg ich mir dann auf der Box genau dieses Verzeichnis /var/lib/freetz an und mache dann:
Rich (BBCode):
# ls -l /var/lib/freetz/
#
# mount -o bind /var/media/ftp/4_GB/python/lib/freetz/ /var/lib/freetz/
#
# ls -l /var/lib/freetz/
-rwxr--r--    1 root     root         35096 Mar  6 23:51 ld-uClibc-1.0.37.so
-rwxr--r--    1 root     root         35096 Mar  6 23:51 ld-uClibc.so.0
-rwxr--r--    1 root     root         35096 Mar  6 23:51 ld-uClibc.so.1
lrwxrwxrwx    1 root     root            18 Mar  6 23:51 libcrypto.so -> libcrypto.so.1.0.0
-rwxr-xr-x    1 root     root       1579700 Mar  6 21:03 libcrypto.so.1.0.0
lrwxrwxrwx    1 root     root            18 Mar  6 23:51 libexpat.so -> libexpat.so.1.6.12
lrwxrwxrwx    1 root     root            18 Mar  6 23:51 libexpat.so.1 -> libexpat.so.1.6.12
-rwxr-xr-x    1 root     root        256560 Mar  6 20:50 libexpat.so.1.6.12
lrwxrwxrwx    1 root     root            15 Mar  6 23:51 libffi.so -> libffi.so.6.0.4
lrwxrwxrwx    1 root     root            15 Mar  6 23:51 libffi.so.6 -> libffi.so.6.0.4
-rwxr-xr-x    1 root     root         13584 Mar  6 21:19 libffi.so.6.0.4
-rw-r--r--    1 root     root           132 Mar  3 23:47 libgcc_s.so
-rwxr-xr-x    1 root     root         83468 Mar  6 20:54 libgcc_s.so.1
lrwxrwxrwx    1 root     root            16 Mar  6 23:51 libgmp.so -> libgmp.so.10.3.2
lrwxrwxrwx    1 root     root            16 Mar  6 23:51 libgmp.so.10 -> libgmp.so.10.3.2
-rwxr-xr-x    1 root     root        511204 Mar  6 20:54 libgmp.so.10.3.2
lrwxrwxrwx    1 root     root            15 Mar  6 23:51 libmpc.so -> libmpc.so.3.1.0
lrwxrwxrwx    1 root     root            15 Mar  6 23:51 libmpc.so.3 -> libmpc.so.3.1.0
-rwxr-xr-x    1 root     root        100284 Mar  6 20:58 libmpc.so.3.1.0
lrwxrwxrwx    1 root     root            16 Mar  6 23:51 libmpfr.so -> libmpfr.so.4.1.6
lrwxrwxrwx    1 root     root            16 Mar  6 23:51 libmpfr.so.4 -> libmpfr.so.4.1.6
-rwxr-xr-x    1 root     root        410652 Mar  6 20:57 libmpfr.so.4.1.6
lrwxrwxrwx    1 root     root            19 Mar  6 23:51 libpython2.7.so -> libpython2.7.so.1.0
-rwxr-xr-x    1 root     root       1764876 Mar  6 23:32 libpython2.7.so.1.0
lrwxrwxrwx    1 root     root            19 Mar  6 23:51 libsqlite3.so -> libsqlite3.so.0.8.6
lrwxrwxrwx    1 root     root            19 Mar  6 23:51 libsqlite3.so.0 -> libsqlite3.so.0.8.6
-rwxr-xr-x    1 root     root       1269064 Mar  6 21:08 libsqlite3.so.0.8.6
lrwxrwxrwx    1 root     root            15 Mar  6 23:51 libssl.so -> libssl.so.1.0.0
-rwxr-xr-x    1 root     root        344744 Mar  6 21:03 libssl.so.1.0.0
lrwxrwxrwx    1 root     root            14 Mar  6 23:51 libz.so -> libz.so.1.2.11
lrwxrwxrwx    1 root     root            14 Mar  6 23:51 libz.so.1 -> libz.so.1.2.11
-rwxr-xr-x    1 root     root        104232 Mar  6 20:58 libz.so.1.2.11
#
Jetzt sind wieder Symlinks drinnen, da alles nochmal neu vom PC exportiert wurde. Die libpython library blieb drinnen, kam von einem dynamisch gelinkten Versuch, der auch nicht läuft).

Soweit so gut, aber nun:
Da wird er wohl tatsächlich mit absolutem Pfad nach dem Loader suchen ... das kannst Du ja leicht prüfen, indem Du mittels mount -o bind ... mal die passende Library an der richtigen Stelle "einblendest".
Hier scheitere ich. Ich kann ja nur - soweit mir bekannt ist - unter /var auf der Box schreiben.
readelf sagt: Requesting program interpreter: /usr/lib/freetz/ld-uClibc.so.1

Rich (BBCode):
# mount -o bind /var/media/ftp/4_GB/python/lib/freetz/ld-uClibc.so.1 /usr/lib/freetz/ld-uClibc.so.1
mount: mounting /var/media/ftp/4_GB/python/lib/freetz/ld-uClibc.so.1 on /usr/lib/freetz/ld-uClibc.so.1 failed: No such file or directory
#
# mkdir -p /usr/lib/freetz/
mkdir: can't create directory '/usr/lib/freetz/': Read-only file system



EDIT: Bei der RPATH-Frage hatte ich das hier: https://github.com/Freetz-NG/freetz-ng/discussions/189 im Kopf.
Wenns in dem Thread drinsteht, ich seh's/erkenne es leider nicht.
Den Wrapper hab ich bereits erweitert:
Rich (BBCode):
#!/bin/sh

# Change the value of PYTHONHOME variable and comment LD_LIBRARY_PATH line in
# if you want to use python on an unmodified box. Don't forget to copy all
# libraries python and its modules depend on to ${PYTHONHOME}/lib/freetz.

set -x
export PYTHONHOME="/var/media/ftp/4_GB/python"
[ ! -d /var/lib/freetz ] && mkdir -p /var/lib/freetz
if ! mount | grep "\/var\/lib\/freetz"; then
        mount -o bind ${PYTHONHOME}/lib/freetz/ /var/lib/freetz/
fi
export FREETZ_RPATH=/var/lib/freetz
export FREETZ_LIBRARY_DIR=/var/lib/freetz
#export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}${LD_LIBRARY_PATH:+:}${PYTHONHOME}/lib/freetz"
export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/var/lib/freetz"
exec "${PYTHONHOME}/bin/python2.7.bin" -B "$@"
 
Code:
mkdir /var/lib
cp -a /usr/lib /var/lib
mount -o bind /var/lib /usr/lib
mkdir /usr/lib/freetz
cp <libname> /usr/lib/freetz/
ls -l /usr/lib/freetz
...
 
  • Like
Reaktionen: rolex0815
Damit lauft's natürlich. :D Danke fürs Hinschieben!

Trotzdem jetzt einen Raspberry Pi bestellt.
 
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.