Linux LXDE zeigt nur noch grüne Symbole statt Zahnräder

Mache ein Downgrade.

Oder überlege dir, welche Infos für eine bessere Antwort/Fehleranalyse wohl notwendig sein könnten.

Vielleicht hast du sie beim "Update" kopiert/verschoben, ohne die permissions (X-Flag) zu erhalten.

Dann erkennt der LXDE sie nun nicht mehr als Programm und setzt den falschen MIMETYPE und zeigt Dir damit das falsche Icon ...

Vielleicht sind es auch die permissions. Oder es ist ein Sicherheitsfeature, dass die unbedarfte Ausführung von binarys, die dort so herumliegen, nicht mehr zulässig ist.

Gruß Jobst

Zum vorletzten Beitrag: Im Terminal "ls -l" => ist das x noch gesetzt welches zeigt, dass die Programme ausführber sind? Ansonsten kann man das sicher auch in dem Dateimanager im Kontext-Menü einstellen / einsehen.

Michael schrieb:

bisher wurden von mir selbst geschriebene C/C++ Programme nach dem Kompilieren und Linken von LXDE / PCManFM immer als Zahnräder angezeigt. Man konnte sie zum Ausführen anklicken.

Nach einem Update erscheinen dieselben Programme nur noch als grüne Symbole, als Dateityp wird "Gemeinsame Bibliothek" angegeben.

Dieselben unveränderten Binaries? Oder irgendwas neu kompiliertes?

Michael schrieb:

bisher wurden von mir selbst geschriebene C/C++ Programme nach dem Kompilieren und Linken von LXDE / PCManFM immer als Zahnräder angezeigt. Man konnte sie zum Ausführen anklicken.

Wie bekomme ich wieder Zahnräder angezeigt?

Wenn LXDE das ähnlich macht wie KDE, dann sind die Menüeinträge kleine Dateien mit Informationen drin, darunter dem Pfad zur Icon-Datei. Möglicherweise ist diese Datei beim Update gelöscht oder umbenannt worden. Wenn das der Fall ist, könnte ein Sym- oder Hardlink an der alten Location helfen.

Jobst M. schrieb:

Dann erkennt der LXDE sie nun nicht mehr als Programm

Weil der nicht die Libraries von magic(1) benutzt? 8-O

Ich habe nur upgedatet und sonst nichts verändert.

Wenn ich eine der C-Dateien in Geany neu kompiliere und linke, werden sie von Geany wie gewohnt ausgeführt. Anschließend erscheinen aber auch diese neu erstellten Dateien in PCManFM als auf der Spitze stehende grüne Quadrate, die nicht ausgeführt werden, wenn man sie anklickt.

Ich kann jetzt gerade nicht an den PC um nachzuschauen, schätze aber, dass sie von den Permissions her nach wie vor ausführbar sind. Shell-Scripts erscheinen nach wie vor als Zahnräder.

Ich glaube, es ist ein Problem von PCManFM.

auf dem grünen Symbol: rechte Maustaste - Eigenschaften, was wird da angezeigt

"astro_plan_pos_2" hatte ich vor längerer Zeit mit einem Pascal-Compiler erstellt

Die "Kommandos zum Erstellen" verwende ich seit Jahren, ich habe sie nicht geändert

Und noch die Attribute im Detail.

Wie gesagt, ich habe nichts geändert, nur über "Synaptic Paketverwaltung" ein Update gemacht: Neu laden - Alle Aktualisierungen vormerken - Anwenden.

Sorry - zweimal dasselbe Bild

Mach mal im Verzeichnis fertig "file *" statt "ls -l"

Edit: nebenbei: die Berechtigungen rwxrwxrwx sind eigentlich immer falsch. Normal will man rwxr-xr-x

file * liefert:

astro_plan_pos_2: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, for GNU/Linux 2.4.0, stripped

download_webp_2: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=e230542b615c22a6a8592e83136fff99633c60c3, for GNU/Linux 3.2.0, not stripped

Alle anderen Programme liefern bis auf die Build-Id das gleiche wie "download_webp_2".

Ich habe nie mit der Compiler-Option -pie oder ähnlichem experimentiert. Ich glaube, dass "pie executable" und "dynamically linked" eine Fehleinschätzung sind.

Michael schrieb:

astro_plan_pos_2: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, for GNU/Linux 2.4.0, stripped

download_webp_2: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=e230542b615c22a6a8592e83136fff99633c60c3, for GNU/Linux 3.2.0, not stripped

Ich habe nie mit der Compiler-Option -pie oder ähnlichem experimentiert. Ich glaube, dass "pie executable" und "dynamically linked" eine Fehleinschätzung sind.

Die meisten Linux-Distributionen verwenden heute Address Space Randomization, das Code an zufällige Speicheradressen lädt, und dadurch die Risiken einiger Sicherheitsfehlerklassen wie Pufferüberläufe verringert. Damit ASLR korrekt funktioniert, muß die Datei als positionsunabhängiger Code (PIE) übersetzt sein. Die meisten Distributionen machen das heute standardmäßig, indem sie ihre GNU-Compiler mit der Option "--enable-default-pie" übersetzen, so daß diese standardmäßig PIE-Executables erzeugen. Wenn Du das nicht möchtest, kannst Du es jedoch mit "-fno-pie" oder dem Shortcut "-no-pie" beim Aufruf Deines gcc(1) verhindern.

Außerdem sind Deine Programme mit Ausnahme des astro_plan_pos_2 nicht gestrippt, enthalten also noch Debuginformationen und nicht benötigte Sektionen. Wenn Du nicht planst, Deine Programme mit einem Debugger wie dem gdb(1), Memorycheckern wie valgrind(1) oder Profilern auszuführen, dann benötigst Du die Debugsymbole wahrscheinlich nicht und kannst dann Deine Programmdateien mit strip(1) kleiner machen.

Weiterhin hat der Benutzer Bauform B. vollkommen Recht, Schreibrechte sind für "group" höchstwahrscheinlich nicht nötig und für "world" erst Recht nicht. Du kannst sie daher mit "chmod go-w <datei(en)>" entfernen und hast damit noch ein weiteres potentielles Sicherheitsrisiko behoben.

Was die Icons Deiner Executables angeht, so hat die Anzeige mit allerhöchster Wahrscheinlichkeit nichts mit den Executables oder ihren Permissions zu tun, sondern mit dem Dateimanager. Entweder ist die Konfiguration der Zuordnungen von Icons zu Dateitypen nicht korrekt, oder er erkennt die Dateitypen nicht korrekt. Hinweise könntest Du womöglich erhalten, indem Du den Dateimanager einmal aus der Kommandozeile (lxterminal?) heraus startest und dort auf die Ausgaben achtest, das Programm sollte dort im Idealfalle ausgeben, wenn es Icondateien nicht finden kann oder Dateitypen nicht zuordnen kann. Außerdem dürften Blicke in Dokumentation und Konfiguration des Dateimanagers hilfreich sein, um mehr darüber herauszufinden, wie dieser Dateimanager die Dateitypen erkennt, und welche Icons er ihnen jeweils zuordnet.

Michael schrieb:

Ich habe nie mit der Compiler-Option -pie oder ähnlichem experimentiert. Ich glaube, dass "pie executable" und "dynamically linked" eine Fehleinschätzung sind.

Sind sie nicht. Dasselbe Problem hatte ich vor einigen Jahren bei meinem Arch System auch.

Da hat ein update die default "PIE" generierung eingeschaltet und dann war in sämtlichen Programmen die Erkennung des file Typs kaputt. 2 Wochen später war das dann nachgezogen. Je nachdem was du für ein System hast, bzw. wie oft es eben geupdated wird, löst sich das Problem eventuell in der nächsten Zeit von selbst.

Vielen Dank für die kompetenten und ausführlichen Antworten!

Ich bin inzwischen möglicherweise über das Problem gestolpert, als ich die fertigen Programme mit einem shell script starten wollte:

mike@PC6:~$ cd /home/mike/Privat/geany/fertig

mike@PC6:~/Privat/geany/fertig$ ls -l insgesamt 468 -rwxrwxrwx 1 mike mike 320480 12. Dez 2020 astro_plan_pos_2 -rwxrwxrwx 1 mike mike 16696 2. Jul 2024 download_webp_2 -rwxrwxrwx 1 mike mike 25304 22. Jan 15:09 fox_sender_2 -rwxrwxrwx 1 mike mike 17088 10. Okt 2023 ingv_daten_auswerten_3 -rwxrwxrwx 1 mike mike 16800 7. Nov 2023 ingv_download_1 -rwxrwxrwx 1 mike mike 22424 18. Apr 2024 ingv_karte_3 -rwxrwxrwx 1 mike mike 16576 22. Mai 2024 ingv_karte_imagemagick_2 -rwxrwxrwx 1 mike mike 16920 7. Nov 2023 maxima_stoppen_7

mike@PC6:~/Privat/geany/fertig$ ./ingv_download_1 ./ingv_download_1: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./ingv_download_1)

Ich habe laut synaptic Paketverwaltung u. a. avr-libc und libc6 installiert. Eine Suche nach "glibc" verlief aber ergebnislos.

Michael schrieb:

mike@PC6:~/Privat/geany/fertig$ ./ingv_download_1 ./ingv_download_1: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./ingv_download_1)

demnach wäre deine Installation älter, als das Programm vom November 2023??? Jetzt wären vielleicht ein paar Versionsnummern interessant:

1

cd /home/mike/Privat/geany/fertig

2

dpkg -l pcmanfm libc6 gcc

3

strings /lib/x86_64-linux-gnu/libc.so.6 | grep 'release version'

4

echo $LD_LIBRARY_PATH

5

/sbin/ldconfig -p | grep libc.so.6

6

cat /etc/os-release

Ich habe laut synaptic Paketverwaltung u. a. avr-libc und libc6 installiert. Eine Suche nach "glibc" verlief aber ergebnislos.

Das ist normal und ok. Die Library heißt libc, das Paket libc6 und GLIBC_xx ist "nur" ein internes Symbol der gnu-libc (oder so ähnlich).

Ich verwende jetzt in Geany beim Linken die Optionen -s und -no-pie.

Die damit erzeugten Programme werden als Zahnräder dargestellt und sind aus dem Dateimanager heraus wie gewohnt durch Anklicken ausführbar.

Nochmals vielen Dank für die kompetenten und ausführlichen Antworten!

Na gut ;) Aber wie zum Henker findet der pcmanfm den Unterschied zwischen astro_plan_pos_2 und download_webp_2? Mein pcmanfm kann das nicht.

Bauform B. schrieb:

Na gut ;) Aber wie zum Henker findet der pcmanfm den Unterschied zwischen astro_plan_pos_2 und download_webp_2? Mein pcmanfm kann das nicht.

Wird halt eine andere Version sein und diese beiden Versionen werden unterschiedlich tief in die ELF-Struktur schauen.

Wobei natürlich das Ergebnis der bei Michael laufenden Version ganz klar falsch ist. Die Unterschiede machen aus der ausführbaren Datei noch lange keine Bibliothek. Da wurde wohl ein Analysefehler nicht korrekt abgefangen.

Linux LXDE zeigt nur noch grüne Symbole statt Zahnräder

Tja... hättest mal lieber die blaue Pille genommen... ;)

SCNR