Liebe Mitleser, trotz googlen und Suche in diversen Listenarchiven kann ich keine Antwort auf die Frage im Subject finden. Anlass ist der vergebliche Versuch, ein Programm zu starten. Es meldet ein undefiniertes Symbol: $> ./programm ./<programm>: symbol lookup error: ./<programm>: undefined symbol: initPAnsiStrings Ich habe z.B. "readelf" benutzt, werde jedoch nicht schlau aus der Ausgabe (die Ziele mit der Nennung des Symbols sehe ich wohl). Eigentlich ist das ja keine Programmierfrage, denn normalerweise weiß man ja als Programmierer, gegen welche Libs der eigene Code gelinkt ist, weshalb man dann wohl auch die Symbole dieser Libs kennt. Also, wenn es nicht zu OT ist, dann wäre ich für Denkanstöße sehr dankbar! Gruß, Tom -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-programming-de+owner@opensuse.org
Hallo, Am Sun, 08 Jan 2012, Thomas Michalka schrieb:
trotz googlen und Suche in diversen Listenarchiven kann ich keine Antwort auf die Frage im Subject finden. Anlass ist der vergebliche Versuch, ein Programm zu starten. Es meldet ein undefiniertes Symbol:
$> ./programm ./<programm>: symbol lookup error: ./<programm>: undefined symbol: initPAnsiStrings
for f in /usr/lib64/lib*.so.? ; do \ strings "$f" | grep -q initPAnsiStrings && echo "$f";\ done HTH, -dnh -- cat /kat/ n. A furry keyboard cover -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-programming-de+owner@opensuse.org
Hallo David, hallo Thomas, hallo Leute, Am Montag, 9. Januar 2012 schrieb David Haller:
Am Sun, 08 Jan 2012, Thomas Michalka schrieb:
trotz googlen und Suche in diversen Listenarchiven kann ich keine Antwort auf die Frage im Subject finden. Anlass ist der vergebliche Versuch, ein Programm zu starten. Es meldet ein undefiniertes Symbol:
$> ./programm ./<programm>: symbol lookup error: ./<programm>: undefined symbol: initPAnsiStrings
for f in /usr/lib64/lib*.so.? ; do \ strings "$f" | grep -q initPAnsiStrings && echo "$f";\ done
Da ist Google aber deutlich performanter - und funktioniert sogar, wenn das entsprechende Paket nicht installiert ist ;-) http://www.google.de/search?q=initPAnsiStrings Der zweite Treffer führt zu https://bbs.archlinux.org/viewtopic.php?id=76197 Gruß Christian Boltz -- "Anybody who really thinks /bin/true should report a version number and a help string (or even a copyright notice) needs to get his head examined." [Linus Torvalds] -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-programming-de+owner@opensuse.org
Hallo Christian, Christian Boltz schrieb:
Hallo David, hallo Thomas, hallo Leute,
Am Montag, 9. Januar 2012 schrieb David Haller:
Am Sun, 08 Jan 2012, Thomas Michalka schrieb:
trotz googlen und Suche in diversen Listenarchiven kann ich keine Antwort auf die Frage im Subject finden. Anlass ist der vergebliche Versuch, ein Programm zu starten. Es meldet ein undefiniertes Symbol:
$> ./programm ./<programm>: symbol lookup error: ./<programm>: undefined symbol: initPAnsiStrings for f in /usr/lib64/lib*.so.? ; do \ strings "$f" | grep -q initPAnsiStrings && echo "$f";\ done
Da ist Google aber deutlich performanter - und funktioniert sogar, wenn das entsprechende Paket nicht installiert ist ;-)
http://www.google.de/search?q=initPAnsiStrings
Der zweite Treffer führt zu https://bbs.archlinux.org/viewtopic.php?id=76197
Habe ich auch gefunden, aber nachdem ich einerseits die 32-bit- und die 64-bit-Version der libjpeg.so.62 installiert habe, dort aber initPAnsiStrings nicht drin steht und es andererseits die libborqt-6.9-qt2.3.so für eine oS-11.0 nicht zu geben scheint, habe ich erst nicht weiter gebohrt. Vielleicht sollte ich nachsehen, ob ich sie irgendwoher bekomme, nur um sicher zu gehen, dass das betreffende Symbol tatsächlich drin ist. Der zweite Tipp dort führt auch nicht so recht weiter, denn $> ldd -r <programm> zeigt zwar jede Menge "undefinded symbols" (auch initPAnsiStrings), aber keine Lib, die es nicht findet. Also wird dann libborqt-6.9-qt2.3.so überhaupt gebraucht? Jetzt habe ich sie mir mal bei rpmfind geholt und festgestellt, dass dort initPAnsiStrings enthalten ist. Ein Installationsversuch allerdings klappt nicht recht, da rpm "Failed Dependencies" reklamiert, obwohl die benötigten Libs alle da sind. Wahrscheinlich ist es halt das falsche Paket für oS-11.0. Ich habe es doch mal mit --nodeps probiert. Wie aber kann ich es dem <programm> klarmachen, dass die Lib jetzt da ist? Ist ja schon etwas spät B-| -- ich probiere morgen weiter. Vielleicht hat ja die eine oder andere 'Nachteule' noch eine Idee. Ciao, Tom
Gruß
Christian Boltz
-- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-programming-de+owner@opensuse.org
On Tue, 10 Jan 2012 00:43:52 +0100, Thomas Michalka
Ein Installationsversuch allerdings klappt nicht recht, da rpm "Failed Dependencies" reklamiert, obwohl die benötigten Libs alle da sind.
Gaaaaaaany dumme Idee! Wenn die Bibliothek für eine andere Distribution gebaut wurde sind die Chancen sehr gross, dass es nicht passt. Die *einzige* sichere Methode ist, das Paket für die eigene Distribution zu bauen, sprich mittels rpmbuild aus dem .src.rpm.
Wahrscheinlich ist es halt das falsche Paket für oS-11.0. Ich habe es doch mal mit --nodeps probiert.
Sehr dumme Idee.
Wie aber kann ich es dem <programm> klarmachen, dass die Lib jetzt da ist?
Korrekt bauen. Wenn das Paket dann korrekt installiert wird sollte eigentlich alles wie gewünscht funktionieren, allerdings nur, wenn die Bibliothek dynamisch gelinkt wird. Richtige Klarheit bietet da nur die Analyse des Quellcodes der streikenden Applikation. Philipp -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-programming-de+owner@opensuse.org
Hallo David, David Haller schrieb:
Hallo,
Am Sun, 08 Jan 2012, Thomas Michalka schrieb:
trotz googlen und Suche in diversen Listenarchiven kann ich keine Antwort auf die Frage im Subject finden. Anlass ist der vergebliche Versuch, ein Programm zu starten. Es meldet ein undefiniertes Symbol:
$> ./programm ./<programm>: symbol lookup error: ./<programm>: undefined symbol: initPAnsiStrings
for f in /usr/lib64/lib*.so.? ; do \ strings "$f" | grep -q initPAnsiStrings && echo "$f";\ done
Aha, "strings" war es, was ich 'gesucht' habe. Dankeschön! Da ich jetzt nicht nur den einen Pfad durchsuchen will, versuche ich es mit $> find / -maxdepth 5 -type f -name lib*.so.? -print0 | xargs -0 strings -f | grep initPAnsiStrings ... und werde leider auch nicht fündig. Die Lib ist wohl gar nicht installiert, deshalb findet das <programm> sie auch nicht und kann daher nicht starten. Daher ist, diesmal hoffentlich präziser formuliert, die Frage: Wie finde ich heraus, in welcher nicht installierten Lib das Symbol initPAnsiStrings definiert ist? Dann müsste ich herausfinden können, welches Paket mir fehlt (über die Abhängigkeiten geht's nicht, da das Programm von extern in einem TGZ-File geliefert wurde). Gruß, Tom -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-programming-de+owner@opensuse.org
On Mon, 09 Jan 2012 15:17:58 +0100, Thomas Michalka
Wie finde ich heraus, in welcher nicht installierten Lib das Symbol initPAnsiStrings definiert ist?
Im Programm wird nicht festgehalten, aus welcher Bibliothek ein Symbol stammt. Damit kann es auch kein Tool geben, dass diese Information liefert. Wenn ein Programm normal dynamisch gelinkt wird, wird im Programm festgehalten, welche Bibliotheken benötigt werden (DTNEEDED Einträge im ELF-Header, die man sich mit "objdump -p <programm>" anzeigen lassen kann). Dann kann man die aufgeführten Bibliotheken überprüfen, aber das erledigt auch schon ldd. Wenn dagegen die nötige Bibliothek mittels dlopen geöffnet wird, hilft nur ein Blick in den Quellcode der Applikation. Philipp -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-programming-de+owner@opensuse.org
Hallo, Philipp Thomas schrieb:
On Mon, 09 Jan 2012 15:17:58 +0100, Thomas Michalka
wrote: [...]
Wenn ein Programm normal dynamisch gelinkt wird, wird im Programm festgehalten, welche Bibliotheken benötigt werden (DTNEEDED Einträge im ELF-Header, die man sich mit "objdump -p <programm>" anzeigen
$> objdump <programm> ... Dynamic Section: NEEDED libX11.so.6 NEEDED libpthread.so.0 NEEDED libdl.so.2 NEEDED libc.so.6 ... Das sind alle NEEDED-Einträge. Wie ich in meiner anderen Mail, auf die Du geantwortet hast, schon schrieb, ergibt ldd -r <programm> u.a. initPAnsiStrings als undefiniertes Symbol. Frage dazu: Warum ist dann die Lib, in der das Symbol definiert ist, nicht unter den NEEDED-Einträge des Programms aufgelistet?
lassen kann). Dann kann man die aufgeführten Bibliotheken überprüfen, aber das erledigt auch schon ldd.
Richtig. Hier habe ich aber auch keinen Hinweis auf die libborqt-6.9-qt2.3.so; wieso nicht, wenn das undefinierte Symbol darin definiert ist? übrigens ist das neben einem Symlink die einzige Datei in dem RPM-Paket gewesen, das ich installiert habe. Ich hätte sie wohl auch aus einem *.tar.gz holen und manuell nach /usr/lib kopieren können. Ich wollte u.a. sehen, ob initPAnsiStrings darin enthalten ist. Zusätzlich frage ich, ob es genügt, die Lib an die richtige Stelle zu kopieren, damit der Dynamic Linker/Loader (/lib/ld-linux.so.2) diese Lib beim Programmstart laden kann. Kannst Du dazu was sagen? Gruß, Tom -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-programming-de+owner@opensuse.org
On Tue, 10 Jan 2012 12:51:10 +0100, Thomas Michalka
Warum ist dann die Lib, in der das Symbol definiert ist, nicht unter den NEEDED-Einträge des Programms aufgelistet?
Mir fallen zwei mögliche Gründe ein. Zum einen könnte es sich um eine indirekte Abhängigkeit handeln, sprich eine der in NEEDED verzeichneten Bibliotheken benötigt das Symbol (unwahrscheinlich in diesem Fall) oder aber die Bibliothek wird explizit mittels dlopen geladen und dann die benötigten Symbole mittels dlsym eingebunden. Sicheren Aufschluss können nur die Quellen des Pakets liefern.
Richtig. Hier habe ich aber auch keinen Hinweis auf die libborqt-6.9-qt2.3.so; wieso nicht, wenn das undefinierte Symbol darin definiert ist?
Im Binary werden die Informationen unabhängig von einander gespeichert. Da ist zum einen der Name der Bibliothek gegen die das Programm gelinkt wird und zum anderen das benötigte Symbol. Es wird beim Linken nicht festgehalten, aus welcher Bibliothek welches Symbol benutzt wurde.
übrigens ist das neben einem Symlink die einzige Datei in dem RPM-Paket gewesen, das ich installiert habe. Ich hätte sie wohl auch aus einem *.tar.gz holen und manuell nach /usr/lib kopieren können. Ich wollte u.a. sehen, ob initPAnsiStrings darin enthalten ist.
Wenn die Bibliothek nicht für die Distribution gebaut wurde sollte man das nicht probieren sondern die Bibliothek für die eigene Distribution kompilieren. Deshalb gib doch bitte an, um welches Programm es sich handelt und eine URL zum Quellcode des Programms. Dann kann ich mir den Code selber mal ansehen und evtl. entdecken, was da schief geht. Die URL zu dem Quellpaket von libborqt-6.9-qt2.3.so wäre auch nicht schlecht. Philipp
Zusätzlich frage ich, ob es genügt, die Lib an die richtige Stelle zu kopieren, damit der Dynamic Linker/Loader (/lib/ld-linux.so.2) diese Lib beim Programmstart laden kann. Kannst Du dazu was sagen?
Wo der dynamische Linker ld-linux.so die Bibliotheken sucht ist in /etc/ld.so.conf festgehalten. Wenn die Bibliothek in einem der angegebenen Veryeichnisse liegt wird sie bei Bedarf geladen. Philipp -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-programming-de+owner@opensuse.org
Hallo, Am Wed, 11 Jan 2012, Philipp Thomas schrieb:
On Tue, 10 Jan 2012 12:51:10 +0100, Thomas Michalka
Warum ist dann die Lib, in der das Symbol definiert ist, nicht unter den NEEDED-Einträge des Programms aufgelistet?
Mir fallen zwei mögliche Gründe ein. Zum einen könnte es sich um eine indirekte Abhängigkeit handeln, sprich eine der in NEEDED verzeichneten Bibliotheken benötigt das Symbol (unwahrscheinlich in diesem Fall) oder aber die Bibliothek wird explizit mittels dlopen geladen und dann die benötigten Symbole mittels dlsym eingebunden. Sicheren Aufschluss können nur die Quellen des Pakets liefern.
'strings' kann aber schon (evtl. sogar ausreichende) Hinweise geben, z.B.:
,----[ foo.c ]
| int answer(void) {
| return 42;
| }
`----
,----[ dlopen_demo.c ]
| #include
Richtig. Hier habe ich aber auch keinen Hinweis auf die libborqt-6.9-qt2.3.so; wieso nicht, wenn das undefinierte Symbol darin definiert ist?
Im Binary werden die Informationen unabhängig von einander gespeichert. Da ist zum einen der Name der Bibliothek gegen die das Programm gelinkt wird und zum anderen das benötigte Symbol. Es wird beim Linken nicht festgehalten, aus welcher Bibliothek welches Symbol benutzt wurde.
Jap. @Thomas: Vgl. auch oben ;)
übrigens ist das neben einem Symlink die einzige Datei in dem RPM-Paket gewesen, das ich installiert habe. Ich hätte sie wohl auch aus einem *.tar.gz holen und manuell nach /usr/lib kopieren können. Ich wollte u.a. sehen, ob initPAnsiStrings darin enthalten ist.
Wenn die Bibliothek nicht für die Distribution gebaut wurde sollte man das nicht probieren sondern die Bibliothek für die eigene Distribution kompilieren.
Sofern das möglich ist: definitiv.
Wo der dynamische Linker ld-linux.so die Bibliotheken sucht ist in /etc/ld.so.conf festgehalten. Wenn die Bibliothek in einem der angegebenen Veryeichnisse liegt wird sie bei Bedarf geladen.
Und dann wäre da noch LD_LIBRARY_PATH ... Daß _du_ das vergisst, Philipp ... *tsk* :-P -dnh -- Microsoft Windows Setup scheint den Bootsektor von Brain 1.0 zu ueberschreiben, was dazu fuehrt, dass Brain am naechsten Morgen nicht mehr gestartet wird. -- Juergen P. Meier in dcsf -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-programming-de+owner@opensuse.org
participants (4)
-
Christian Boltz
-
David Haller
-
Philipp Thomas
-
Thomas Michalka