Leap 15.2 findet existierende Datei nicht

mkossmann · 22 Feb. 2021

Ich hätte da noch eine vielleicht blöde Idee zu deinem Problem:
Wenn das Binary mit der rpath Option gelinkt wurde, wird im Binary der gesamte Pfad zur Bibiliothek verewigt. Und es wird dann meines Wissens auch nur in diesem Verzeichnis nach der Bibliothek gesucht. Nun sind aber im Laufe der letzten Jahre einige der Bibliotheken an andere Stellen gewandert. Z.B. X11 von /usr/X11R6 nach /usr. Und zwischen 15.1 und 15.2 im Rahme des "/usr merge" einiges von /lib nach /usr/lib. Das Erstere würde dein Problem bei 15.1 erklären, das Zweite die Verschärfung bei der 15.2 .
Man könnte also mal mit "readelf -d binary-or-library |head -20" sich vorhandene rpaths anschauen

Hazel · 23 Feb. 2021

Hallo,

ich bin weiterhin tief verstrickt in die Untersuchung "meines" Sorgenkind-Programms START_Linux.

Von Sauerland kam die Empfehlung, die Ausgabe des Befehls

Code:

ldd ./START_Linux

genauer unter die Lupe zu nehmen. Was in meinem Fall dabei herauskam, steht in meinem Betrag 2021-Feb-22, 12:13 pm. Bis auf die HEX-Zahlen in Klammern ist alles identisch zu dem, was Sauerland in 2021-Feb-21, 1:54 pm berichtet hat. Soweit haben wir also festen Boden unter den Füßen.

Ich habe nun die library-Verweise aus dem ldd-Befehl durch zypper untersuchen lassen. Hier ein Beispiel:

Code:

hazel@fujitsu152:~> zypper se --provides libmount.so.1
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...

S | Name            | Summary              | Type
--+-----------------+----------------------+------
i | libmount1       | Device mount library | Paket
i | libmount1-32bit | Device mount library | Paket
hazel@fujitsu152:~>

Beim Abklappern aller Ausgaben von ldd mittels zypper lautet das Ergebnis so.

Zusammenfassend lässt sich feststellen, dass fast überall in der ersten Spalte jeweils "i" oder "i+" steht. D.h. die entsprechenden Module sind installiert. Es gibt aber auch Einzelfälle ähnlich diesem hier:

Code:

hazel@fujitsu152:~> zypper se --provides libstdc++.so.6
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...

S  | Name                  | Summary                     | Type
---+-----------------------+-----------------------------+------
i  | libstdc++6            | Dynamische C++-Bibliotheken | Paket
i+ | libstdc++6-32bit      | Dynamische C++-Bibliotheken | Paket
   | libstdc++6-gcc7       | Dynamische C++-Bibliotheken | Paket
   | libstdc++6-gcc7-32bit | Dynamische C++-Bibliotheken | Paket
   | libstdc++6-gcc8       | Dynamische C++-Bibliotheken | Paket
   | libstdc++6-gcc8-32bit | Dynamische C++-Bibliotheken | Paket
hazel@fujitsu152:~>

Ich weiß nicht, ob hier die teilweise fehlenden Anzeigen "i" oder "i+" in der ersten Spalte beunruhigend sein müssen. Auf alle Fälle erlaubt es mir zypper nicht, ein Paket aus den Zeilen 3 bis 6 dieser Liste zu installieren, ohne gleichzeitig eines aus den ersten beiden Zeilen wegzunehmen. Und genau das habe ich bisher nicht gewagt.

Ihr seht an der Länge dieses Textes, dass ich einigermaßen ratlos bin, wie ich weitermachen könnte.

Und ach ja: Der Vorschlag von mkossmann (Danke dafür!) übersteigt meine Kompetenzen doch beträchtlich. Ohne eine gewissen Zeitaufwand für meine Einarbeitung werde ich auf diesem Weg nicht weiterkommen können.

Viele Grüße
Hazel

Sauerland · 23 Feb. 2021

Startet es jetzt?

mkossmann · 23 Feb. 2021

Zeig zuerst mal nur die Ausgabe in der Konsole von "readelf -d START_Linux | head -20".

Damit sollte man entscheiden können, ob in in der Programmdatei rpaths vorhanden sind und ob sie falsch sind

Hazel · 23 Feb. 2021

Sauerland schrieb:
Startet es jetzt?

Leider nein. Die Situation ist identisch jener vor einigen Tagen (siehe 2021-Feb-20, 12:13 pm):

Code:

hazel@fujitsu152:/data/althome/hazel/EnglischDVD/DATA> ./START_Linux
Gtk-Message: 21:05:48.754: Failed to load module "unity-gtk-module"
Speicherzugriffsfehler (Speicherabzug geschrieben)
hazel@fujitsu152:/data/althome/hazel/EnglischDVD/DATA>

Ich sollte vielleicht nochmals betonen, dass alles, was ich seit dem o.a. Zeitpunkt hier geschrieben habe, auf dem Desktop-PC geschah, der das Programm immerhin zum Start brachte. Auf dem in der Anfangsphase erwähnten Notebook geschah beim Programmaufruf gar nichts, auch keine Fehlermeldung. Ich möchte in dieser Diskussion hier nicht zwischen zwei Maschinen hin-und-her springen, weil ich mich dann nach einiger Zeit selbst nicht mehr auskennen würde. (Der andere Grund ist der, dass das Notebook vorzugsweise durch andere Familienmitglieder genutzt wird.)

Grüße
Hazel

Hazel · 23 Feb. 2021

mkossmann schrieb:
Zeig zuerst mal nur die Ausgabe in der Konsole von "readelf -d START_Linux | head -20".

Damit sollte man entscheiden können, ob in in der Programmdatei rpaths vorhanden sind und ob sie falsch sind

Code:

hazel@fujitsu152:/data/althome/hazel/EnglischDVD/DATA> readelf -d START_Linux | head -20

Dynamic section at offset 0x5abbf8 contains 40 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: [libX11.so.6]
 0x00000001 (NEEDED)                     Shared library: [libXt.so.6]
 0x00000001 (NEEDED)                     Shared library: [libgtk-x11-2.0.so.0]
 0x00000001 (NEEDED)                     Shared library: [libgdk-x11-2.0.so.0]
 0x00000001 (NEEDED)                     Shared library: [libpthread.so.0]
 0x00000001 (NEEDED)                     Shared library: [libgthread-2.0.so.0]
 0x00000001 (NEEDED)                     Shared library: [libsqlite3.so.0]
 0x00000001 (NEEDED)                     Shared library: [libidn.so.11]
 0x00000001 (NEEDED)                     Shared library: [libXxf86vm.so.1]
 0x00000001 (NEEDED)                     Shared library: [librt.so.1]
 0x00000001 (NEEDED)                     Shared library: [libstdc++.so.6]
 0x00000001 (NEEDED)                     Shared library: [libm.so.6]
 0x00000001 (NEEDED)                     Shared library: [libgcc_s.so.1]
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]
 0x00000001 (NEEDED)                     Shared library: [libdl.so.2]
 0x00000001 (NEEDED)                     Shared library: [libSM.so.6]
 0x00000001 (NEEDED)                     Shared library: [libgdk_pixbuf-2.0.so.0]
hazel@fujitsu152:/data/althome/hazel/EnglischDVD/DATA>

Einiges hier sichtbare kennen wir schon (siehe 2021-Feb-22, 12:13 pm):

Code:

hazel@fujitsu152:/data/althome/hazel/EnglischDVD/DATA> objdump -p START_Linux | grep -i needed
  NEEDED               libX11.so.6
  NEEDED               libXt.so.6
  NEEDED               libgtk-x11-2.0.so.0
  NEEDED               libgdk-x11-2.0.so.0
  NEEDED               libpthread.so.0
  NEEDED               libgthread-2.0.so.0
  NEEDED               libsqlite3.so.0
  NEEDED               libidn.so.11
  NEEDED               libXxf86vm.so.1
  NEEDED               librt.so.1
  NEEDED               libstdc++.so.6
  NEEDED               libm.so.6
  NEEDED               libgcc_s.so.1
  NEEDED               libc.so.6
  NEEDED               libdl.so.2
  NEEDED               libSM.so.6
  NEEDED               libgdk_pixbuf-2.0.so.0
  NEEDED               libpango-1.0.so.0
  NEEDED               libgobject-2.0.so.0
  NEEDED               libglib-2.0.so.0
  NEEDED               libXinerama.so.1
hazel@fujitsu152:/data/althome/hazel/EnglischDVD/DATA>

Aber gibt es darüber hinaus etwas Neues?

Grüße
Hazel