dvdauthor und libcdio - Install-Prob.

[worker]

Hallo,

hoffe es kann mir hier jemand nen Tipp geben ...

Wollte dvdauthor 0.6.11 installieren, der verlangt aber zuerst libcdio.
OK, libcdio 0.77 installiert. Installation verlief sauber.
Jetzt wieder dvdauthor "./configure" --> und da meckert er immer noch, dass keine
libcdio-libraries installiert sind.

Kann mir bitte jemand sagen, wo/wie ich das Problem lösen kann ?
Vielen Dank im Vorraus.
Worker

PS: Ach ja sorry - hab Mandriva 2006

 

[traffic]

Du musst die letzten 20 Zeilen der Ausgabe von ./configure komplett und originalgetreu ins Forum kopieren.

Oder fertige Binärpakete verwenden. Es gibt ganz bestimmt welche für Mandriva.

 

[Anonymous]

ließ das mal durch, wenn du manuell installiert haben solltest.
Quelle: http://www.linux-praxis.de/lpic1/lpi101/1.102.4.html

Wenn neue Libraries installiert werden sollen, dann stellt sich die Frage, wohin. Zunächst einmal bieten sich die Verzeichnisse /lib, /usr/lib und /usr/local/lib an. Sollen aber neue Verzeichnisse angelegt werden, die Libraries enthalten, dann muß das der internen Verwaltung der Libraries mitgeteilt werden.

Die interne Verwaltung der Libraries wird durch den Aufruf des Programms ldconfig vollzogen. Dieses Programm wartet den Library Cache und erstellt automatisch die notwendigen symbolischen Links auf Libraries. Der Librarie-Cache liegt in der Datei /etc/ld.so.cache und enthält eine binär codierte Liste aller dem System bekannten Libraries.

Damit ldconfig diese Datei erstellen kann und auch neu hinzugekommene Libraries dort aufgenommen werden, muß ldconfig wissen, welche Verzeichnisse nach Libraries durchsucht werden sollen. ldconfig durchsucht zunächst die beiden Verzeichnisse /usr/lib und /lib, danach alle Verzeichnisse, die in der Datei /etc/ld.so.conf aufgelistet sind.

Wenn also ein neues Programm foo installiert wird, das seine Shared Libraries im Verzeichnis /usr/local/foo/lib ablegt, so müssen wir nur dieses Verzeichnis in die Datei /etc/ld.so.conf aufnehmen. Nach der Installation neuer Libraries und/oder der Neuaufnahme von Pfaden in der Datei /etc/ld.so.conf muß das Programm ldconfig ausgeführt werden, bevor die neuen Libraries verwendet werden können. Erst nach dem Aufruf von ldconfig stehen sie ja in der Datei /etc/ld.so.cache und sind somit dem Linker/Loader bekannt.

danach dann als root ldconfig und configure noch mal versuchen

robi

 

[worker]

@traffic:

Also, ich muss mich leider korrigieren (hatte gestern vor lauter "Installations-Wut" irgendwie den Durchblick verloren :-( )
Das dvdauthor ging (normal) zu installieren es ist das Proggi "vcdimager-0.7.23" das mir die o.g. Probleme bereitet.
Ich habe jetzt die letzten 20 Zeilen von vcdimager ins Forum gepostet:

checking for strptime... yes
checking for libpopt library... no or not new enough - need libpopt 1.7 or greater
checking for ANSI C header files... (cached) yes
checking for sys/stat.h... (cached) yes
checking for stdint.h... (cached) yes
checking for inttypes.h... (cached) yes
checking stdbool.h usability... yes
checking stdbool.h presence... yes
checking for stdbool.h... yes
checking sys/mman.h usability... yes
checking sys/mman.h presence... yes
checking for sys/mman.h... yes
checking whether byte ordering is bigendian... no
checking for an ANSI C-conforming const... yes
checking for inline... inline
checking whether gcc supports ISO C99 _Pragma()... yes
checking how to create empty arrays... []
checking bitfield ordering in structs... LSBF
checking for pkg-config... /usr/bin/pkg-config
checking for libcdio >= 0.72... configure: error: Required libcdio library not found. Please get libcdio from http://www.gnu.org/software/libcdio/ and install it.

Er meckert zwar über "libpopt", macht da aber weiter.



@robi:
Gute Info - danke.
Was ich noch gern wüsste ist, werden die zu installierende Libraries normaler weise bei jedem (zu kompilierendem) Programm mitgeliefert ?
Ich hoffe, ich habe jetzt nicht was falsch verstanden.
Thx.

 

[Anonymous]

Was ich noch gern wüsste ist, werden die zu installierende Libraries normaler weise bei jedem (zu kompilierendem) Programm mitgeliefert ?

Sehr viele Programme, und Pakete die im Namen schon irgendwas mit lib heißen sowieso, erzeugen wenn sie kompiliert werden Librarys diese werden dann bei make install auch in die entsprechenden Verzeichnisse kopiert.
Typische Verzeichnisse sind ZB /lib /usr/lib /opt/kde3/lib /opt/gnome/lib /usr/local/lib /usr/X11R6/lib

Dort befinden sich unter anderem folgende Dateien

Dateien mit der Endung .a .la sind statische Librarys, diese können bei der Kompilation schon fest in das neu zu kompilierende Programm eingebaut werden. Jedes Programm trägt dann also eine Kopie dieser Library mit sich im Bauch. Dieses verbraucht natürlich viel Platz, und wird nur noch in Ausnahmefällen automatisch gemacht.

Dateien mit der Endung .o .so sind dynamische Libs, diese können dynamisch in Programme eingebunden werden, das heißt das Lib bleibt wo es ist und wird bei Anforderung in den Speicher geladen und dort können dann allen Porgramme gleichzeitig das Lib nutzen. Allerdings die Programme selbst können das Library nicht selbst laden ( starten) das muss der spezielle Loader tun.

Und dieser Loader muss natürlich wissen, welche Libs er verwalten soll und wo sie sich befinden, desshalb muss die Datenbank aktualisiert werden, wenn neue (dynamische) Libs hinzugekommen sind.

Soll ein Programm kompiliert werden, und dieses Programm benötigt irgendwelche dynamischen Libs, dann prüft das configure ab, indem es versucht das Lib anzusprechen. Wenn jetzt der Loader das Lib nicht kennt, dann gibt es bei configure hier einen Fehler, und wenn das Lib gar nicht da ist, muss es eben vorher erst installiert werden, sonst läuft configure nicht sauber durch.

Bei einigen Programmen die man manuell installiert, kann das dann ganze Rattenschwänze nach sich ziehen, die man dann noch vorher installieren muss, und man mit der Installation eine einzigen Programmes stundenlang beschäftigt sein.

Wer keine Zeit hat, oder sich den ganzen Ärger ersparen will, sollte zum Installieren auf eine intelligente Paketverwaltung zurückgreifen, die sucht solche Abhängigkeiten und die benötigten Programme/Libs und installiert sie vorher selbständig.

robi

 

[worker]

Klasse Beitrag robi !
Vielen vielen Dank für die Infos !
Genau so eine Erklärung hab ich im Net gesucht aber leider nicht gefunden.

Ja, ich habe es schon bemerkt, dass wenn man selbst Prg. kompiliert, sich das ganze hinzieht, weil etliche Abhängigkeiten vorher nicht aufgelöst werden können, weil einfach Pakete fehlen (nicht installiert sind).

Aber wenn Du jetzt .rpm & Co. meinst, um mir das ganze zu vereinfachen ... ich habe gelesen, dass das auch nicht das wahre ist und das es besser ist die Prg. selber zu kompilieren - warum allerdings das nicht so "gut" sein soll, weis ich auch nicht genau.
Und so plage ich mich mit dem kompilieren ... jedenfalls bis heute.
Ich galube, ich werde bei manchen Prgs. doch einfach auf .rpm zurückgreifen.

Jedenfalls vielen Dank für die Erklärung ;-)

 

[admine]

Ich galube, ich werde bei manchen Prgs. doch einfach auf .rpm zurückgreifen.

Und genau in diesem Moment kannst du weitere Probleme bekommen.

RPM greift auf eine Datenbank zu, in der alle Informationen gespeichert sind.
Es werden alle Dateien eingetragen, die mit RPM installiert wurden.
Benötigt jetzt ein RPM ein bestimmt Libary, dann schaut RPM in diese Datenbank und findet sie nicht => Abhängigkeitsproblem.
Auch wenn du genau diese Libary schon manuell (./configure, make make install) installiert hast -> die RPM-Datenbank weiß das aber nicht.

Daher meist der Tipp, dass man bei RPMbasierenden Distris möglichst RPMs installieren soll.
Gibt es ein RPM mal wirklich nicht, dann kann man sich mit "checkinstall" ein RPM bauen und es installieren:
http://www.linux-club.de/faq/Software_aus_dem_Quelltext_Installieren/Deinstallieren
(sollte in etwa auch für Mandriva gelten)

 

[worker]

Aha, interessant.
Gibt es denn keinen Weg (Prg./Script) dies der RPM-Datenbank mitzuteilen ?
Also bsplw. nach: configure, make, make install, <hier sag´ ich´s meiner RPM-Datenbank>
(Bzw. könnte dies ja doch schon make install machen.)
Falls nein, dann scheint mir hier ein Loch in den Linux-Installationsmöglichkeiten zu sein.
Aber das wäre ja dann schon bestimmt gelöst worden, oder ?

 

[admine]

Aha, interessant.
Gibt es denn keinen Weg (Prg./Script) dies der RPM-Datenbank mitzuteilen ?
Also bsplw. nach: configure, make, make install, <hier sag´ ich´s meiner RPM-Datenbank>
(Bzw. könnte dies ja doch schon make install machen.)

Nein, gibt es nicht.

Falls nein, dann scheint mir hier ein Loch in den Linux-Installationsmöglichkeiten zu sein.
Aber das wäre ja dann schon bestimmt gelöst worden, oder ?

Dieses Loch "stopft" "checkinstall" ... hast es dir schon mal angesehen Bzw. den geposteten Link ?

 

[worker]

Ah, jetzt, ja. ;-)
Jetzt hat´s "klick" gemacht ;-)
Thx.