Fehlende shared libs

24/04/2008 - 14:54 von Marian Aldenhövel | Report spam
Hallo,

Ich habe ein mit T2 gebautes schmales uClibc-basiertes System
zusammengestellt. Funktioniert so in etwa.

Drauf laufen soll am Ende ein Programm, das bisher in einer auf
dem Linux Router Project aufgebauten Distribution lief. Basis war
damals ein 2.2-er Kernel. Momentan liegt mir besagtes Programm nur
binàr vor. Und das làuft (natürlich) nicht auf meinem neuen System.

Am Ende werde ich wohl diese proprietàre Anwendung für das neue
System auch neu übersetzen, aber ich habe noch keine Quellen dafür.

Meine Frage hier und heute ist aber warum _genau_ làuft es nicht?


-bash-3.2# ./nogo
-bash: ./nogo: No such file or directory

-bash-3.2# file ./nogo


./nogo: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for
GNU/Linux 2.2.5, dynamically linked (uses shared libs), not stripped


-bash-3.2# strace ./nogo
execve("./nogo", ["./nogo"], [/* 9 vars */]) = -1 ENOENT (No such file or
directory)
..



OK. Shared libs fehlen. Habe ich kürzlich hier gelernt.


-bash-3.2# ldd ./nogo
checking sub-depends for '/lib/libc.so.6'
libc.so.6 => /lib/libc.so.6 (0x00000000)
/lib/ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x00000000)



Die gibt es. Bestimmt nicht so ganz passend, aber es gibt sie:


-bash-3.2# ls -l /lib/libuClibc* /lib/libc.so.* /lib/ld-uClibc*
-rwxr-xr-x 1 root root 17000 Apr 24 13:58


/lib/ld-uClibc-0.9.29.so

lrwxrwxrwx 1 root root 19 Apr 24 13:58 /lib/ld-uClibc.so.0


-> ld-uClibc-0.9.29.so

lrwxrwxrwx 1 root root 19 Apr 24 13:58 /lib/libc.so.0 ->


libuClibc-0.9.29.so

lrwxrwxrwx 1 root root 9 Apr 24 14:09 /lib/libc.so.6 ->


libc.so.0

-rw-r--r-- 1 root root 277176 Apr 24 13:58


/lib/libuClibc-0.9.29.so

Zum Vergleich die ldd Ausgabe für ein funktionierendes Programm:


/bin/busybox: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),


dynamically linked (uses shared libs), stripped


-bash-3.2# ldd /bin/busybox
libcrypt.so.0 => /lib/libcrypt.so.0 (0xb7fa8000)
libm.so.0 => /lib/libm.so.0 (0xb7f9c000)
libc.so.0 => /lib/libc.so.0 (0xb7f54000)
ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0xb7fc0000)



Mir fàllt vor allem auf, daß im fail-Fall keine Adressen (0x00000000)
gefunden werden und daß zweitens im fail-Fall die Abhàngigkeit
als "/lib/ld-uClibc.so.0" angegeben wird, im Erfolgsfall als
"ld-uClibc.so.0" also ohne "/lib"-Pràfix.

Kann mir jemand die Ausgabe erklàren und was da "ENOENT" nicht gefunden
wird?

Wenn ich das Ding irgendwie dazu zwànge seine Libs zu finden würde
ich schlimmstenfalls Krach wegen fehlender Symbole oder böse
crashes wegen Inkompatibilitàt erwarten. Dann wàre ich _sicher_ daß
ich neu bauen _muss_ und nicht nur mein neues System unvollstàndig
im Hinblick auf die Systemvoraussetzungen der Anwendung ist.

Ciao, MM
Marian Aldenhövel, Rosenhain 23, 53123 Bonn
http://www.marian-aldenhoevel.de
"Success is the happy feeling you get between the time you
do something and the time you tell a woman what you did."
 

Lesen sie die antworten

#1 Sieghard Schicktanz
25/04/2008 - 00:23 | Warnen spam
Hallo Marian,

Du schriebst am Thu, 24 Apr 2008 14:54:54 +0200:

> checking sub-depends for '/lib/libc.so.6'
> libc.so.6 => /lib/libc.so.6 (0x00000000)


^
> /lib/ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x00000000)

Die gibt es. Bestimmt nicht so ganz passend, aber es gibt sie:


...
> lrwxrwxrwx ... 9 Apr 24 14:09 /lib/libc.so.6 -> libc.so.0


^
Mhmm - "Bestimmt nicht so ganz passend". Wahrscheinlich sogar ganz
unpassend...

Zum Vergleich die ldd Ausgabe für ein funktionierendes Programm:

> -bash-3.2# ldd /bin/busybox


...
> libc.so.0 => /lib/libc.so.0 (0xb7f54000)


^
> ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0xb7fc0000)

Mir fàllt vor allem auf, daß im fail-Fall keine Adressen (0x00000000)



Mir fàllt hier vorallem auf, daß an den markierten Stellen markante
Abweichungen in den numerischen Anteilen der Bibliotheks-Spezifikationen
zu bestehen scheinen. Ich könnte mir durchaus vorstellen, daß der wohl
etwas "einfach gestrickte" Lader der uClibc im Fall der Nicht-Auflösbarkeit
einer Referenz statt des aussagekràftigen Textes "missing" einfach die
"Nicht-Adresse" 0 (NULL, NIL) ausgibt, um dem Benutzer das Problem zu
melden.
Möglicherweise verlangt Dein Programm "nogo" einfach ein Symbol / Symbole
von der libc, die ihm die (diese) uClibc einfach nicht bieten kann, oder
versucht eine Lader-Funktion anzusprechen, die dieser nicht kennt. Bei
Versionsunterschieden in der libc ist das durchaus ein beliebter Effekt,
und manchmal erhàlt man dazu sogar passende Fehlermeldungen.
Du könntest ja mal untersuchen, _was_ Dein Programm von der libc so alles
haben möchte, und vergleichen, ob das Deine uClibc überhaupt anbietet.
"nm" könnte Dir dabei ggfs. etwas helfen.

Wenn ich das Ding irgendwie dazu zwànge seine Libs zu finden würde
ich schlimmstenfalls Krach wegen fehlender Symbole oder böse
crashes wegen Inkompatibilitàt erwarten. Dann wàre ich _sicher_ daß



Du hast die offenbar schon - nur nicht als solche erkannt...

-
(Weitergabe von Adressdaten, Telefonnummern u.à. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder àhnlichem)
Mit freundlichen Grüßen, S. Schicktanz

Ähnliche fragen