Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Problem mit shared library
2 views
Skip to first unread message
Edzard Egberts
Apr 15, 2013, 7:57:18 AM4/15/13
to
Ich bin hier am herumbasteln und ï¿œbersehe irgend etwas grundsï¿œtzliches:
Weil es mir zu lange dauert, direkt auf meinem Slackware-Board zu
compilieren, habe ich auf dem PC ein virtuelles Slackware eingerichtet
und damit ein paar Bibliotheken und ein Programm gebaut, dass diese
Bibliotheken verwendet. Die Bibliotheksdateien sind dabei
(praktischerweise) alle im Verzeichnis /usr/local/lib gelandet. Im
nï¿œchsten Schritt habe ich dann die /usr/local/lib und das Programm auf
ein "jungfrï¿œuliches" System kopiert und versucht das Programm
auszufï¿œhren - "error while loading shared libraries: libexiv2.so.5:
cannot open shared object file: No such file or directory".
Erst einmal die ï¿œblichen Verdï¿œchtigen: Alles wurde richtig kopiert und
ist vorhanden, "/usr/local/lib" ist in der "ld.so.conf" eingetragen und
"ldconfig" lï¿œuft ohne Fehlermeldung durch. Dann habe ich noch
LD_LIBRARY_PATH mit "/usr/local/lib" belegt und das hï¿œtte nun wirklich
funktionieren mï¿œssen, wenn es nur am Pfad liegt.
Woran kann das denn noch liegen?
Weil es mir zu lange dauert, direkt auf meinem Slackware-Board zu
compilieren, habe ich auf dem PC ein virtuelles Slackware eingerichtet
und damit ein paar Bibliotheken und ein Programm gebaut, dass diese
Bibliotheken verwendet. Die Bibliotheksdateien sind dabei
(praktischerweise) alle im Verzeichnis /usr/local/lib gelandet. Im
nï¿œchsten Schritt habe ich dann die /usr/local/lib und das Programm auf
ein "jungfrï¿œuliches" System kopiert und versucht das Programm
auszufï¿œhren - "error while loading shared libraries: libexiv2.so.5:
cannot open shared object file: No such file or directory".
Erst einmal die ï¿œblichen Verdï¿œchtigen: Alles wurde richtig kopiert und
ist vorhanden, "/usr/local/lib" ist in der "ld.so.conf" eingetragen und
"ldconfig" lï¿œuft ohne Fehlermeldung durch. Dann habe ich noch
LD_LIBRARY_PATH mit "/usr/local/lib" belegt und das hï¿œtte nun wirklich
funktionieren mï¿œssen, wenn es nur am Pfad liegt.
Woran kann das denn noch liegen?
Edzard Egberts
Apr 15, 2013, 8:24:46 AM4/15/13
to
Edzard Egberts schrieb:
ist keine libexiv2.so.5 vorhanden, nur eine libexiv2.so.12. Wieder alles
rï¿œberkopiert und lï¿œuft immer noch nicht. Warum wird denn das Programm
mit einer Verknï¿œpfung gebaut, die nicht (oder nicht ohne weiteres
auffindbar) vorhanden ist? Mir aber auch grundsï¿œtzlich schleierhaft,
warum es zu einer Bibliothek immer zig Verknï¿œpfungen mit irgend einer
Nummer gibt...
> libexiv2.so.5: cannot open shared object file
>
>
> Erst einmal die ï¿œblichen Verdï¿œchtigen: Alles wurde richtig kopiert und
> ist vorhanden
Hmpf, das wird ja immer schrï¿œger: Noch einmal alles gebaut und diesmal
> ist vorhanden
ist keine libexiv2.so.5 vorhanden, nur eine libexiv2.so.12. Wieder alles
rï¿œberkopiert und lï¿œuft immer noch nicht. Warum wird denn das Programm
mit einer Verknï¿œpfung gebaut, die nicht (oder nicht ohne weiteres
auffindbar) vorhanden ist? Mir aber auch grundsï¿œtzlich schleierhaft,
warum es zu einer Bibliothek immer zig Verknï¿œpfungen mit irgend einer
Nummer gibt...
Rainer Weikusat
Apr 15, 2013, 10:42:32 AM4/15/13
to
Edzard Egberts <ed...@tantec.de> writes:
> Ich bin hier am herumbasteln und �bersehe irgend etwas grunds�tzliches:
> ein "jungfr�uliches" System kopiert und versucht das Programm
> auszuf�hren - "error while loading shared libraries: libexiv2.so.5:
> LD_LIBRARY_PATH mit "/usr/local/lib" belegt und das h�tte nun wirklich
> funktionieren m�ssen, wenn es nur am Pfad liegt.
ist, die auf dem Zielsystem nicht existiert. Das koennte man mit ldd
ueberpruefen.
> Ich bin hier am herumbasteln und �bersehe irgend etwas grunds�tzliches:
>
> Weil es mir zu lange dauert, direkt auf meinem Slackware-Board zu
> compilieren, habe ich auf dem PC ein virtuelles Slackware eingerichtet
> und damit ein paar Bibliotheken und ein Programm gebaut, dass diese
> Bibliotheken verwendet. Die Bibliotheksdateien sind dabei
> (praktischerweise) alle im Verzeichnis /usr/local/lib gelandet. Im
> n�chsten Schritt habe ich dann die /usr/local/lib und das Programm auf
> Weil es mir zu lange dauert, direkt auf meinem Slackware-Board zu
> compilieren, habe ich auf dem PC ein virtuelles Slackware eingerichtet
> und damit ein paar Bibliotheken und ein Programm gebaut, dass diese
> Bibliotheken verwendet. Die Bibliotheksdateien sind dabei
> (praktischerweise) alle im Verzeichnis /usr/local/lib gelandet. Im
> ein "jungfr�uliches" System kopiert und versucht das Programm
> auszuf�hren - "error while loading shared libraries: libexiv2.so.5:
> cannot open shared object file: No such file or directory".
>
> Erst einmal die �blichen Verd�chtigen: Alles wurde richtig kopiert und
>
> ist vorhanden, "/usr/local/lib" ist in der "ld.so.conf" eingetragen
> und "ldconfig" l�uft ohne Fehlermeldung durch. Dann habe ich noch
> LD_LIBRARY_PATH mit "/usr/local/lib" belegt und das h�tte nun wirklich
> funktionieren m�ssen, wenn es nur am Pfad liegt.
>
> Woran kann das denn noch liegen?
ZB daran, dass die Bibliothek selber gegen eine Bibliothek gelinkt
> Woran kann das denn noch liegen?
ist, die auf dem Zielsystem nicht existiert. Das koennte man mit ldd
ueberpruefen.
Heinrich Wolf
Apr 15, 2013, 10:43:22 AM4/15/13
to
"Edzard Egberts" <ed...@tantec.de> schrieb im Newsbeitrag
news:kkgrie$lin$1...@gwaiyur.mb-net.net...
ln libexiv2.so.12 libexiv2.so
oder
ln libexiv2.so.5 libexiv2.so
odfer so ï¿œhnlich
Edzard Egberts
Apr 15, 2013, 10:56:33 AM4/15/13
to
Rainer Weikusat schrieb:
wesentlich aufw�ndiger ist, als von mir erwartet: Die libexiv2.so.5 ist
in /usr/lib/ eingetragen und verkn�pft auf /usr/local/lib/.
Zwischendurch habe ich noch herausgefunden, dass diese inflation�ren
so-Nummern die Version der Bin�rschnittstelle darstellen soll, was ich
aber f�r Quark halte, weil 6 Verkn�pfungen nicht 6 Bin�rschnittstellen
erzeugen k�nnen. Au�erdem ist noch eine F�lle von weiteren Dateien
notwendig und das wurde mir dann zu bl�d, weil das auch noch eine
kommerzielle Lib ist - die wird dann eben nicht gekauft.
Also zur�ck zur statischen libexif, die stolz behauptet, Lesen,
Editieren und Schreiben von exif w�re damit n�tig. Die Entwickler
bedauern nur, dass leider kein Beispiel zur Verf�gung steht, wie man mit
dieser Bibliothek in echt ein Bild mit ge�nderter Exif speichert. :o/
Man m�sste aber ein freifliegendes exif erzeugen und selber mit dem Bild
zusammenmurksen k�nnen, da bin ich ja mal gespannt...
> Edzard Egberts<ed...@tantec.de> writes:
>> Erst einmal die �blichen Verd�chtigen: Alles wurde richtig kopiert und
>> ist vorhanden, "/usr/local/lib" ist in der "ld.so.conf" eingetragen
>> und "ldconfig" l�uft ohne Fehlermeldung durch. Dann habe ich noch
>> LD_LIBRARY_PATH mit "/usr/local/lib" belegt und das h�tte nun wirklich
>> funktionieren m�ssen, wenn es nur am Pfad liegt.
>>
>> Woran kann das denn noch liegen?
>
> ZB daran, dass die Bibliothek selber gegen eine Bibliothek gelinkt
> ist, die auf dem Zielsystem nicht existiert. Das koennte man mit ldd
> ueberpruefen.
ldd habe ich schon gefunden und dabei entdeckt, dass die Installation
>> Erst einmal die �blichen Verd�chtigen: Alles wurde richtig kopiert und
>> ist vorhanden, "/usr/local/lib" ist in der "ld.so.conf" eingetragen
>> und "ldconfig" l�uft ohne Fehlermeldung durch. Dann habe ich noch
>> LD_LIBRARY_PATH mit "/usr/local/lib" belegt und das h�tte nun wirklich
>> funktionieren m�ssen, wenn es nur am Pfad liegt.
>>
>> Woran kann das denn noch liegen?
>
> ZB daran, dass die Bibliothek selber gegen eine Bibliothek gelinkt
> ist, die auf dem Zielsystem nicht existiert. Das koennte man mit ldd
> ueberpruefen.
wesentlich aufw�ndiger ist, als von mir erwartet: Die libexiv2.so.5 ist
in /usr/lib/ eingetragen und verkn�pft auf /usr/local/lib/.
Zwischendurch habe ich noch herausgefunden, dass diese inflation�ren
so-Nummern die Version der Bin�rschnittstelle darstellen soll, was ich
aber f�r Quark halte, weil 6 Verkn�pfungen nicht 6 Bin�rschnittstellen
erzeugen k�nnen. Au�erdem ist noch eine F�lle von weiteren Dateien
notwendig und das wurde mir dann zu bl�d, weil das auch noch eine
kommerzielle Lib ist - die wird dann eben nicht gekauft.
Also zur�ck zur statischen libexif, die stolz behauptet, Lesen,
Editieren und Schreiben von exif w�re damit n�tig. Die Entwickler
bedauern nur, dass leider kein Beispiel zur Verf�gung steht, wie man mit
dieser Bibliothek in echt ein Bild mit ge�nderter Exif speichert. :o/
Man m�sste aber ein freifliegendes exif erzeugen und selber mit dem Bild
zusammenmurksen k�nnen, da bin ich ja mal gespannt...
Rainer Weikusat
Apr 15, 2013, 11:10:24 AM4/15/13
to
Edzard Egberts <ed...@tantec.de> writes:
> Edzard Egberts schrieb:
>> libexiv2.so.5: cannot open shared object file
>>
>> Erst einmal die 锟絙lichen Verd锟絚htigen: Alles wurde richtig kopiert und
> Edzard Egberts schrieb:
>> libexiv2.so.5: cannot open shared object file
>>
>> ist vorhanden
>
> Hmpf, das wird ja immer schr锟絞er: Noch einmal alles gebaut und diesmal
> ist keine libexiv2.so.5 vorhanden, nur eine libexiv2.so.12. Wieder
> alles r锟絙erkopiert und l锟絬ft immer noch nicht. Warum wird denn das
> Programm mit einer Verkn锟絧fung gebaut, die nicht (oder nicht ohne
> weiteres auffindbar) vorhanden ist? Mir aber auch grunds锟絫zlich
> schleierhaft, warum es zu einer Bibliothek immer zig Verkn锟絧fungen mit
> irgend einer Nummer gibt...
Diese 'irgendeine Nummer' ist die Versionsnummer der Bibliothek. Falls
als Beispiel mal annimmt, dass die Versionen 3.7 and 4.1 der
Bibliothek 'durcheinander' auf einem System installiert sind, sollte
das wie folgt aussehen:
- eine regulaere Datei libdurcheinander.so.3.7
- einen symlink libdurcheinander.so.3 -> libdurcheinander.so.3.7
- eine regulaere4 Datei libdurcheinander.so.4.1
- einen symlink libdurcheinander.so.4 -> libdurcheinander.so.4.1
- einen symlink libdurcheinander.so -> libdurcheinander.so.4.1
Die unterschiedlichen 'major versions' (3.x und 4.x) stuenden hier
fuer wechselseiting inkompatible Versionen einer Bibliothek gleichen
Namens und die 'minor versions' .7 and .1 fuer 'patch level'. Es
waere also das siebte update der Bibliothek 'durcheinander Version 3'
installiert und das erste der Bibliothek 'durcheinander Version
4'. Eine Anwendung koennte gegen irgendeinen dieserf Namen gelinkt
werden um mehr oder minder spezifisch die gewuenschte
Bibliotheksversion zu bestimmte (libdurcheinander.so => die neueste,
libdurcheinander.so.4 => neuestes Update von Version 4,
libdurcheinander.so.4.1 => Version 4.1 und keine andere).
Allerdings ist das seit ca 1999 obsolet weil es mittlerweile
Versionsinformation pro 'Symbol' in einer dynamischen Bibliothek gibt
(weil die 'major version' der C-Library seit damals aus politischen
Gruenden auf 6 festgelegt ist).
Insofern hier noch irgendetwas klar war, sollte das jetzt wohl
beseitigt worden sein :->.
Edzard Egberts
Apr 16, 2013, 2:00:09 AM4/16/13
to
>> Mir aber auch grunds�tzlich schleierhaft, warum es zu einer
>> Bibliothek immer zig Verkn�pfungen mit irgend einer Nummer gibt...
�hnlich durch. Was ich so verwirrend fand - die eigentliche Lib hatte
die Endung "12.2.0.0", dazu gibt es Verkn�pfungen mit ".5", ".5.3.0",
".12", ".12.2.0". Also Version 12.2 mit "kompatibler Schnittstelle" zu
Version 5.3?
> Allerdings ist das seit ca 1999 obsolet weil es mittlerweile
> Versionsinformation pro 'Symbol' in einer dynamischen Bibliothek
> gibt (weil die 'major version' der C-Library seit damals aus
> politischen Gruenden auf 6 festgelegt ist).
>
> Insofern hier noch irgendetwas klar war, sollte das jetzt wohl
> beseitigt worden sein :->.
Zumindest wei� ich wieder mehr dar�ber, was ich alles nicht wei�. Das
mit den Bibliotheken ist ja wesentlich umfangreicher, als ich gedacht
h�tte, mit allerhand Tools zum Laden und Anpassen. Na ja, jetzt wird
erst einmal etwas Low-Level gebastelt, dass ist meistens ganz
erquicklich. :o)
>> Bibliothek immer zig Verkn�pfungen mit irgend einer Nummer gibt...
>
> Diese 'irgendeine Nummer' ist die Versionsnummer der Bibliothek.
> Falls als Beispiel mal annimmt, dass die Versionen 3.7 and 4.1 der
> Diese 'irgendeine Nummer' ist die Versionsnummer der Bibliothek.
> Falls als Beispiel mal annimmt, dass die Versionen 3.7 and 4.1 der
> Die unterschiedlichen 'major versions' (3.x und 4.x) stuenden hier
> fuer wechselseiting inkompatible Versionen einer Bibliothek gleichen
> Namens und die 'minor versions' .7 and .1 fuer 'patch level'.
Das w�re logisch und �blich, sogar ich nummeriere meine Software so
> fuer wechselseiting inkompatible Versionen einer Bibliothek gleichen
> Namens und die 'minor versions' .7 and .1 fuer 'patch level'.
�hnlich durch. Was ich so verwirrend fand - die eigentliche Lib hatte
die Endung "12.2.0.0", dazu gibt es Verkn�pfungen mit ".5", ".5.3.0",
".12", ".12.2.0". Also Version 12.2 mit "kompatibler Schnittstelle" zu
Version 5.3?
> Allerdings ist das seit ca 1999 obsolet weil es mittlerweile
> Versionsinformation pro 'Symbol' in einer dynamischen Bibliothek
> gibt (weil die 'major version' der C-Library seit damals aus
> politischen Gruenden auf 6 festgelegt ist).
>
> Insofern hier noch irgendetwas klar war, sollte das jetzt wohl
> beseitigt worden sein :->.
mit den Bibliotheken ist ja wesentlich umfangreicher, als ich gedacht
h�tte, mit allerhand Tools zum Laden und Anpassen. Na ja, jetzt wird
erst einmal etwas Low-Level gebastelt, dass ist meistens ganz
erquicklich. :o)
0 new messages