Welches Verzeichnis fuer selbstkompilierte Ogg-Tools?
Hallo Liste, ich hatte mir gestern mal die neuesten Ogg-Vorbis-Tarballs von www.vorbis.org heruntergezogen. Dabei sind ein paar Probleme und Fragen aufgetaucht: Die Dateien sind die folgenden: libao-0.8.3.tar.gz libogg-1.0.tar.gz libvorbis-1.0.tar.gz vorbis-tools-1.0.tar.gz Ich habe eine SuSE7.3, und die im Moment installierten Versionen sind mir einfach zu alt (oggenc Version 0.8) Gut, libao installierte sich wunderbar, libogg ebenfalls (Habe immer mit checkinstall gearbeitet). Bei libvorbis ging es dann los, er meckerte bei "make" rum dass er "/usr/lib/libogg.so" nicht finden konnte. Habe dann ein wenig rumgetestet, und dank rpm kam ich dahinter dass die von mir kompilierte Version nach /usr/local/lib/ installiert wurde und nicht nach /usr/lib/. Klingt ja eigentlich auch logisch, alles Eigenes nach *local* zu kopieren, aber _wieso_ suchen die Pakete dann nicht auch dort nach ihren Komponenten? Ich musste das Problem durch Anpassung des "configure"-Skriptes loesen, und dann ging es. Ist das normal? BTW Ich habe obwohl es funktioniert hatte dann doch wieder die SuSE-Pakete installiert, da sich die Neuen doch nicht korrekt in mein System eingebunden hatten. Ich konnte nicht mehr ueber den Konqueror (KDE 3.0.3) auf eine Audio-CD zugreifen ("audiocd:/"). Es kam immer irgend so eine Fehlermeldung von wegen KIO_slave oder so... weiss ich nicht mehr genau. Ich verwende zwar eh lieber die Kommandozeile, aber irgendwie schien es ja Probleme zu geben... Auf der SuSE-Seite habe ich jedenfalls keine aktuellen Pakete gefunden, solche Updates scheint es nur in Verbindung mit neuen Disti-Versionen zu geben... Was hat es mit den Verzeichnissen auf sich? Oder sind einfach nur die aktuellen Tarballs buggy? Gruss Florian -- TCPA? Nein Danke! http://www.konsumboykott.de
Florian Evers wrote:
ich hatte mir gestern mal die neuesten Ogg-Vorbis-Tarballs von www.vorbis.org heruntergezogen. Dabei sind ein paar Probleme und Fragen aufgetaucht:
Die Dateien sind die folgenden:
libao-0.8.3.tar.gz libogg-1.0.tar.gz libvorbis-1.0.tar.gz vorbis-tools-1.0.tar.gz
Ich habe eine SuSE7.3, und die im Moment installierten Versionen sind mir einfach zu alt (oggenc Version 0.8)
Hoffentlich hast Du die alten Version deinstalliert, bevor Du ans Installieren der neuen Versionen gegangen bist. Sonst gibt es Chaos...
Gut, libao installierte sich wunderbar, libogg ebenfalls (Habe immer mit checkinstall gearbeitet). Bei libvorbis ging es dann los, er meckerte bei "make" rum dass er "/usr/lib/libogg.so" nicht finden konnte. Habe dann ein wenig rumgetestet, und dank rpm kam ich dahinter dass die von mir kompilierte Version nach /usr/local/lib/ installiert wurde und nicht nach /usr/lib/. Klingt ja eigentlich auch logisch, alles Eigenes nach *local* zu kopieren, aber _wieso_ suchen die Pakete dann nicht auch dort nach ihren Komponenten? Ich musste das Problem durch Anpassung des "configure"-Skriptes loesen, und dann ging es. Ist das normal?
Nein. Bist Du sicher, dass Du nach Installation von libogg und von libao ein "ldconfig" durchgefuehrt hast? Befindet sich ein Eintrag fuer das Verzeichnis /usr/local/lib in der Datei /etc/ld.so.conf? Gruesse, Thomson -- Thomas Hertweck, Dipl.-Geophys. Geophysikalisches Institut, Universitaet Karlsruhe (TH)
Hi Thomas, Thomas Hertweck [Thomas.Hertweck@gpi.uni-karlsruhe.de] schrieb:
Florian Evers wrote:
ich hatte mir gestern mal die neuesten Ogg-Vorbis-Tarballs von www.vorbis.org heruntergezogen. Dabei sind ein paar Probleme und Fragen aufgetaucht:
Ich habe eine SuSE7.3, und die im Moment installierten Versionen sind mir einfach zu alt (oggenc Version 0.8)
Hoffentlich hast Du die alten Version deinstalliert, bevor Du ans Installieren der neuen Versionen gegangen bist. Sonst gibt es Chaos...
Ja danke, das wars gewesen! Ich dachte naemlich, dass "checkinstall" die alten RPM's entfernt, aber da waren noch zwei weitere RPM's aktiv, die alles durcheinander gebracht hatten (libogg-devel und libvorbis-devel). Also nochmals alles was nach Vorbis klang per "rpm -e --nodeps" deinstalliert, dann klappte es (fast).
Gut, libao installierte sich wunderbar, libogg ebenfalls (Habe immer mit checkinstall gearbeitet). Bei libvorbis ging es dann los, er meckerte bei "make" rum dass er "/usr/lib/libogg.so" nicht finden konnte. Habe dann ein wenig rumgetestet, und dank rpm kam ich dahinter dass die von mir kompilierte Version nach /usr/local/lib/ installiert wurde und nicht nach /usr/lib/. Klingt ja eigentlich auch logisch, alles Eigenes nach *local* zu kopieren, aber _wieso_ suchen die Pakete dann nicht auch dort nach ihren Komponenten? Ich musste das Problem durch Anpassung des "configure"-Skriptes loesen, und dann ging es. Ist das normal?
Nein. Bist Du sicher, dass Du nach Installation von libogg und von libao ein "ldconfig" durchgefuehrt hast? Befindet sich ein Eintrag fuer das Verzeichnis /usr/local/lib in der Datei /etc/ld.so.conf?
Okay, _das_ hat sich erledigt. Nach der Installation von "vorbis-tools" fehlte immer noch "ogg123", was wegen einer fehlenden Library nicht mitkompiliert wurde (curl/libcurl). Habe ich jetzt nachinstalliert, jetzt hapert es aber direkt an der Kompilation von ogg123! :-( Gehe ich in das Verzeichnis ogg123, und tippe "make", gibt es gcc -O20 -ffast-math -fsigned-char -o ogg123 audio.o buffer.o callbacks.o cfgfile_options.o cmdline_options.o file_transport.o format.o http_transport.o ogg123.o oggvorbis_format.o playlist.o status.o transport.o ../share/libutf8.a ../share/libgetopt.a /usr/local/lib/libvorbisfile.so /usr/local/lib/libvorbis.so -lm /usr/local/lib/libogg.so /usr/local/lib/libao.so -lnsl /usr/lib/libcurl.so -L/usr/ssl/lib -lssl -lcrypto -ldl -lpthread -Wl,--rpath -Wl,/usr/local/lib -Wl,--rpath -Wl,/usr/local/lib /usr/i486-suse-linux/bin/ld: cannot find -lssl collect2: ld returned 1 exit status make: *** [ogg123] Error 1 Diese Option "-lssl" bringt ihn durcheinander, aber ich weiss nichts damit anzufangen. In dem Makefile taucht nichts aus, scheint daher von einem anderen Tool zu stammen... (Libtool?). Naja egal, ist ja nur der Player! (XMMS sei Dank) :-) Leider klappt jetzt wieder das Auslesen von Audio-CD's nicht mehr, der Konqueror meldet wieder: [--snip--] Beim Laden von audiocd:/ ist folgender Fehler aufgetreten: Prozess konnte nicht gestartet werden: Aufruf des Ein/Ausgabe-Moduls nicht möglich. klauncher meldet: Fehler beim Laden von "kio_audiocd" [--snap--] Aber ich denke damit kann ich leben, auch wenn ich es schade finde... wenn es nur _dabei_ bleibt. Gruss Florian -- TCPA? Nein Danke! http://www.konsumboykott.de
Florian Evers wrote:
Thomas Hertweck [Thomas.Hertweck@gpi.uni-karlsruhe.de] schrieb:
[...] Hoffentlich hast Du die alten Version deinstalliert, bevor Du ans Installieren der neuen Versionen gegangen bist. Sonst gibt es Chaos...
Ja danke, das wars gewesen! Ich dachte naemlich, dass "checkinstall" die alten RPM's entfernt, aber da waren noch zwei weitere RPM's aktiv, die alles durcheinander gebracht hatten (libogg-devel und libvorbis-devel).
Nein, checkinstall installiert die kreierten RPMS mit gewissen Optionen, die Du z.B. in der Datei /etc/checkinstallrc finden kannst. Eventuell solltest Du diese anpassen, IIRC steht da naemlich bei SuSE so etwas wie "--nodeps --force" drin, was nicht unbedingt so gut ist... Ein Deinstallieren von aelteren RPMs vor dem Compilieren des neuen Sourcecodes ist auf alle Faelle angebracht.
[...] Gehe ich in das Verzeichnis ogg123, und tippe "make", gibt es
gcc -O20 -ffast-math -fsigned-char -o ogg123 audio.o buffer.o callbacks.o cfgfile_options.o cmdline_options.o file_transport.o format.o http_transport.o ogg123.o oggvorbis_format.o playlist.o status.o transport.o ../share/libutf8.a ../share/libgetopt.a /usr/local/lib/libvorbisfile.so /usr/local/lib/libvorbis.so -lm /usr/local/lib/libogg.so /usr/local/lib/libao.so -lnsl /usr/lib/libcurl.so -L/usr/ssl/lib -lssl -lcrypto -ldl -lpthread -Wl,--rpath -Wl,/usr/local/lib -Wl,--rpath -Wl,/usr/local/lib /usr/i486-suse-linux/bin/ld: cannot find -lssl collect2: ld returned 1 exit status make: *** [ogg123] Error 1
Diese Option "-lssl" bringt ihn durcheinander, aber ich weiss nichts damit anzufangen. In dem Makefile taucht nichts aus, scheint daher von einem anderen Tool zu stammen... (Libtool?). Naja egal, ist ja nur der Player! (XMMS sei Dank) :-)
Diese Meldung kommt vom Linker (ld) und bedeutet, dass das Archiv libssl.a nicht gefunden wird. Es befindet sich im Paket openssl-devel, was Du vermutlich nicht installiert hast --> nachholen!
Leider klappt jetzt wieder das Auslesen von Audio-CD's nicht mehr, der Konqueror meldet wieder: [--snip--] Beim Laden von audiocd:/ ist folgender Fehler aufgetreten: Prozess konnte nicht gestartet werden: Aufruf des Ein/Ausgabe-Moduls nicht möglich. klauncher meldet: Fehler beim Laden von "kio_audiocd" [--snap--]
Hmm, dazu kann ich leider wenig sagen, kenne mich in den In- terna von KDE nicht so aus. Eventuell hilft es mal, in Run- level 3 das /tmp Verzeichnis zu saeubern... - hat hier jeden- falls bei vielen KDE Problemen schon eine Loesung gebracht :) Gruesse, Thomson -- Thomas Hertweck, Dipl.-Geophys. Geophysikalisches Institut, Universitaet Karlsruhe (TH)
Hi Thomas, Thomas Hertweck [Thomas.Hertweck@gpi.uni-karlsruhe.de] schrieb:
Florian Evers wrote:
Thomas Hertweck [Thomas.Hertweck@gpi.uni-karlsruhe.de] schrieb:
[...] Hoffentlich hast Du die alten Version deinstalliert, bevor Du ans Installieren der neuen Versionen gegangen bist. Sonst gibt es Chaos...
Ja danke, das wars gewesen! Ich dachte naemlich, dass "checkinstall" die alten RPM's entfernt,
Nein, checkinstall installiert die kreierten RPMS mit gewissen Optionen, die Du z.B. in der Datei /etc/checkinstallrc finden kannst. Eventuell solltest Du diese anpassen, IIRC steht da naemlich bei SuSE so etwas wie "--nodeps --force" drin, was nicht unbedingt so gut ist... Ein Deinstallieren von aelteren RPMs vor dem Compilieren des neuen Sourcecodes ist auf alle Faelle angebracht.
Ok, aber was ist an --nodeps so schlimm? Ich habe doch lediglich schon vorhandene RPM's ersetzt, und die anderen (stoerenden RPM's, die -devel's) waeren trotzdem noch dagewesen. In Zukunft werde ich vorher immer gruendlich aufraeumen, und zwar mit --nodeps (Weil ja andere RPM's im System libvorbis usw. bereits benoetigen), und dann im Anschluss erst das Kompilieren starten und das Ergebnis mit checkinstall und ldconfig installieren. Danke :-)
collect2: ld returned 1 exit status make: *** [ogg123] Error 1
Diese Option "-lssl" bringt ihn durcheinander, aber ich weiss nichts damit anzufangen. In dem Makefile taucht nichts aus, scheint daher von einem anderen Tool zu stammen... (Libtool?). Naja egal, ist ja nur der Player! (XMMS sei Dank) :-)
Diese Meldung kommt vom Linker (ld) und bedeutet, dass das Archiv libssl.a nicht gefunden wird. Es befindet sich im Paket openssl-devel, was Du vermutlich nicht installiert hast --> nachholen!
Okay, danke, jetzt klappt es! :-) Leider kann man sich ja nicht anzeigen lassen, zu welchem Paket eine noch nicht installierte Datei [1] gehoert :-)
Leider klappt jetzt wieder das Auslesen von Audio-CD's nicht mehr, der Konqueror meldet wieder: [--snip--] Beim Laden von audiocd:/ ist folgender Fehler aufgetreten: Prozess konnte nicht gestartet werden: Aufruf des Ein/Ausgabe-Moduls nicht möglich. klauncher meldet: Fehler beim Laden von "kio_audiocd" [--snap--]
Hmm, dazu kann ich leider wenig sagen, kenne mich in den In- terna von KDE nicht so aus. Eventuell hilft es mal, in Run- level 3 das /tmp Verzeichnis zu saeubern... - hat hier jeden- falls bei vielen KDE Problemen schon eine Loesung gebracht :)
Schade, klappt immer noch nicht. Das aktuelle KDE (naja fast, 3.0.3) ist bei mir eh ein wenig durchwachsen, irgendwie muss ich da mal was falsch eingestellt haben, denn nirgends geht mehr die Hilfe... Danke fuer die Tips, haben mir ne Menge gebracht :-) Gruss Florian [1] Insideranmerkung fuer suse-talk-Mitleser: Na klar gibt's sowas!
rpm -qf volker suse-talk-2002.10 volker bash: volker: nicht existent *SCNR* -- TCPA? Nein Danke! http://www.konsumboykott.de
Florian Evers wrote:
[Installation via RPM]
Ok, aber was ist an --nodeps so schlimm? Ich habe doch lediglich schon vorhandene RPM's ersetzt, und die anderen (stoerenden RPM's, die -devel's) waeren trotzdem noch dagewesen. In Zukunft werde ich vorher immer gruendlich aufraeumen, und zwar mit --nodeps (Weil ja andere RPM's im System libvorbis usw. bereits benoetigen), und dann im Anschluss erst das Kompilieren starten und das Ergebnis mit checkinstall und ldconfig installieren. Danke :-)
Wie der Name schon sagt, werden bei gesetzter Option --nodeps keine Abhaengigkeiten ueberprueft. Genau da mag Dein Problem gelegen haben: Nimm an, Du hast ein Paket xyz und ein Paket xyz-devel, die in Deinem System installiert sind und die die gleiche Versionsnummer tragen. Wenn Du nun versuchst, per RPM das Paket xyz zu aktualisieren, dann wird das nicht gehen, weil xyz-devel einen Konflikt ausloesen wird - es benoetigt Paket xyz in genau der richtigen Version. Nur wenn Du gleich- zeitig die Pakete xyz und xyz-devel aktualisiert auf eine neue Version wird es ohne Konflikte funktionieren. Installierst Du nun das Update des Paketes xyz mit z.B. den Optionen --nodeps --force, so werden eben keine Abhaengigkei- ten ueberprueft. Du wirst dann das Paket xyz in einer neueren Version als das Paket xyz-devel auf der Festplatte haben, und somit wird es frueher oder spaeter zu Problemen kommen, da beide Pakete in der Versionsnummer zueinander passen muessen. Ist das einigermassen verstaendlich? Nur wer genau weiss, was er tut, und nur in ganz bestimmten Faellen sollte man die Op- tion --nodeps verwenden...!
Leider kann man sich ja nicht anzeigen lassen, zu welchem Paket eine noch nicht installierte Datei [1] gehoert :-)
Warum nicht? Das sollte per YaST Paketauskunft gehen, oder aber bei gemounteter SuSE-DVD/CD1 sollte ein "zgrep dateiname /cdrom/ARCHIVES.gz" das Paket liefern, in dem die Datei mit dem Namen "dateiname" enthalten ist. Mit "pin" sollte das im Uebrigen auch gehen. Gruesse, Thomson -- Thomas Hertweck, Dipl.-Geophys. Geophysikalisches Institut, Universitaet Karlsruhe (TH)
participants (2)
-
Florian Evers -
Thomas Hertweck