[Problem] ./configure error: Toolchain findet libs nicht

[nmsport]

Das ist keine exakte Antwort.

Nicht? Du hattest nur nach der Größe gefragt und die ist tatsächlich erstmal so und damit wirklich untypisch riesig. Allerdings: Ich habe gerade mal die Größen der Windows-Version des 2.3.2 überschlagen. Die .exe des Servers (Service) ist schon 500 K groß, hinzu kommen ein paar .dlls, die zusammen schon über 2 MB groß sind. Insofern muss ich jetzt wohl freetz jetzt noch einmal komplett neu bauen und noch einmal durchlaufen lassen. Sollte der FTP-Client es wirklich am Ende versaut haben?

Das Transferieren im Textmodus ist einer der häufigsten Gründe, warum ein Programm so abbricht, aber bei anderen funktioniert.

In einer oder zwei Kannen Kaffee kann ich was dazu sagen.

 

[RalfFriedl]

Natürlich ist 2,3MB keine exakte Antwort. Oder meinst Du damit 2,300000MB entspricht 2411724,8Byte?

 

[nmsport]

Bei der Riesendatei, insofern ich sie so nicht erwartet hatte, habe ich freilich nicht aufs Byte genau geschaut, sondern die Werte genommen, wie sich mir in Nautilus und FZ angezeigt werden. Ich hätte da auch kein Mißtrauen, dass da einfach Daten verschwinden oder hinzukommen, weil mir sowas noch nicht begegnet ist. Selbst nicht, wenn ich ich Daten von ext3 via FTP nach FAT32 (32-K-Cluster) transferiere.

Der Hinweis mit dem Transfer-Mode war trotzdem vollkommen richtig. Wer weiß, wie die Automatik des FZ wirklich funktioniert und wie sie mit dem exotischen Code des Binary umgeht, auch wenn mir auf Deb brav "executable" angezeigt wird. Na der Rechner rechnet erstmal wieder.. mal schauen.

 

[RalfFriedl]

Selbst nicht, wenn ich ich Daten von ext3 via FTP nach FAT32 (32-K-Cluster) transferiere.

Es kommt dabei ja auch nicht auf ext3, FAT oder was auch immer an, sondern nur auf den Text-Transfer mit FTP Protokoll.
Du musst dafür übrigens nicht alles neu erstellen, ein neuer Transfer der vorhandenen Datei reicht auch. Wenn die Datei noch nicht gelöscht ist, kannst Du auch die genauen Größen vergleichen, dann weißt DU gleich, ob es daran liegt.

 

[sf3978]

Bei der Riesendatei, insofern ich sie so nicht erwartet hatte, ...

Evtl. kannst Du auf die eine oder andere lib oder auf curl verzichten, so dass dein statisch gelinktes binary etwas kleiner wird:

root@fritz:/var/media/ftp/uStor02/archiv# ldd ./icecast2
        libgpg-error.so.0 => not found
        libc.so.0 => /lib/libc.so.0 (0x2aabe000)
        libssl.so.0.9.8 => /lib/libssl.so.0.9.8 (0x2ab39000)
        libcrypto.so.0.9.8 => /lib/libcrypto.so.0.9.8 (0x2ab79000)
        libdl.so.0 => /lib/libdl.so.0 (0x2ac71000)
        libxslt.so.1 => not found
        libz.so.1 => /lib/libz.so.1 (0x2ac84000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x2aca7000)
        libm.so.0 => /lib/libm.so.0 (0x2acca000)
        libogg.so.0 => not found
        libvorbis.so.0 => not found
        libcurl.so.4 => not found
        libxml2.so.2 => not found
        libgcrypt.so.11 => not found
        libintl.so.8 => not found
        libshout.so.3 => not found
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x2acf2000)
        ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x2aaa8000)

...
$(PKG)_DEPENDS_ON := curl libxml2 libogg libvorbis libgcrypt gettext libshout
$(PKG)_LIBS := -logg -lvorbis -lcurl -lxml2 -lgcrypt -lintl -lshout -all-static
...

 

[nmsport]

Ja, auf curl hätte ich gern verzichtet und nach der Icecast-Doc wäre das auch verzichtbar, wenn man die YP-Schnittstelle nicht benötigt. Die wiederum benötigt man erstens bei Anwendung des Servers auf einem SOHO-Router totsicher nicht, zweitens ist sie hinfällig, weil AOL keine Icecastler auf seinen YPs haben will und das deshalb schon seit langem blockt. Vermutlich ist zwar dann auch kein Eintrag in den Icecast-Serverlisten mehr möglich, aber wie gesagt: Wer braucht das in dem Anwendungsfall, der hier vorliegt?

Das kann ich aber alles später noch probieren, falls es überhaupt klappt, das ding lauffähig zu bekommen.

 

[sf3978]

..., falls es überhaupt klappt, das ding lauffähig zu bekommen.

Wenn Du bereit bist, icecast2 mit der download-toolchain eines neu ausgecheckten trunk statisch gelinkt zu kompilieren, dann wird es auch klappen.

 

[nmsport]

Hab ich doch schon. Jedesmal wieder tapfer von ganz vorn. Nun: Komplett neu gebaut und: Tadaaa:

# /var/media/ftp/Kingston-DataTravelerG3-01/icecast/icecast2 -h
Icecast 2.3.3

usage: icecast [-b -v] -c <file>
options:
        -c <file>       Specify configuration file
        -v              Display version info
        -b              Run icecast in the background

#

Es waren der FileZilla und sein automatischer Transfermode, die's versaut hatten.

Mein Gott: Soviele Tage Kampf. Speziellen Dank an sf3978 für die Patches! Ohne diese wäre das ja wohl nie gegangen und als Linux-Grünschnabel ist man mit solchen Aufgaben ohne Hilfe wirklich erschossen. Klasse!

Nun noch die Config rübscherschieben und anpassen und dann mal schauen, ob er auch vollumfänglich tut, was er soll.

 

[sf3978]

Nun noch die Config rübscherschieben und anpassen und dann mal schauen, ob er auch vollumfänglich tut, was er soll.

Wenn es tut, bitte deine anonymisierte Config (... für icecast2) hier als Beispiel/howto auch veröffentlichen. Danke.

 

[nmsport]

Also die Config ist [url="http://icecast.org/docs/icecast-2.3.3/icecast2_config_file.html]hier[/url] hervorragend dokumentiert, was mich freilich nicht davon abhalten sollte, eine für die Box sinnvolle hier anzubieten und etwas zu erläutern.

Im Augenblick gibts aber unerwartete Probleme.
Der Serverteil, der für HTML-Transfers verantwortlich ist und den man auch für das Admin-Web-Interface braucht (XSLT-Parser), funktioniert nicht. Entsprechende HTTP-Requests beantwortet der Server mit einem 404 und stürtzt hin und wieder mit segmentation fault ab. Das ist das sichtbare Problem. Dahinter liegt aber scheinbar etwas anderes, und zwar Zugriffe auf das Dateisystem.

Icecast verweigert unter Linux die Ausführung als root, so dass man auf den boxusr80 zurückgreifen muss. Das geht auch zunächst. Da ich weitergehende Probleme mit Rechten vermutete, habe ich dem USB-Stick statt seines ursprünglichen FAT32 ein ext3 verpasst. Darauf kann er aber trotz geänderter Eigentumsverhältnisse nicht zugreifen, auch nicht als root mit Pfad.

Als boxusr80 kann man aber wenigstens die Logfiles und das .pid in /var/tmp ablegen, was ja sogar gut ist. Der Versuch, das Verzeichnis des Webs testweise dort anzulegen, schlägt aber ebenfalls fehl. Ebenfalls verträgt er in der Config keine absoluten Pfadangaben für die public- und admin-webs. Dann schmiert er sofort ab. Nur ./web, also relativ zu seinem eigenen Arbeitsverzeichnis akzeptiert er, aber wie gesagt, im Browser bekommt man nichts außer einer 404, ggf. in der Konsole noch ein seg. fault dazu.

Wahrscheinlich muss man sich den libs nochmal zuwenden und ggf. die Kompilierungsprozess gründlich beobachten. Warnungen waren ja teils massenhaft zu lesen.

Ansonsten: Upstream, Downstream und Relaying funktionieren schon mal wie sie sollten.