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

[Michael (k-mte)]

Hallo,

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.

Wie bekomme ich wieder Zahnräder angezeigt?

[Nemopuk (nemopuk)]

Mache ein Downgrade.

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

[Flip B. (frickelfreak)]

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

[Jobst M. (jobstens-de)]

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

[Gerhard Z. (germel)]

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.

[Ob S. (Firma: 1984now) (observer)]

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?

[Ein T. (ein_typ)]

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.

[Ein T. (ein_typ)]

Jobst M. schrieb:
> Dann erkennt der LXDE sie nun nicht mehr als Programm

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

[Michael (k-mte)]

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.

[Stephan S. (uxdx)]

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

[Michael (k-mte)]

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

[Michael (k-mte)]

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

[Michael (k-mte)]

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

[Bauform B. (bauformb)]

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

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

[Michael (k-mte)]

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.

[Ein T. (ein_typ)]

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.

[M. N. (bmbl2)]

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.

[Michael (k-mte)]

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.

[Bauform B. (bauformb)]

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:

cd /home/mike/Privat/geany/fertig
dpkg -l pcmanfm libc6 gcc
strings /lib/x86_64-linux-gnu/libc.so.6 | grep 'release version'
echo $LD_LIBRARY_PATH
/sbin/ldconfig -p | grep libc.so.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).

[Michael (k-mte)]

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!

[Bauform B. (bauformb)]

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.

[Ob S. (Firma: 1984now) (observer)]

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.

[Ben B. (Firma: Funkenflug Industries) (stromkraft)]

> Linux LXDE zeigt nur noch grüne Symbole statt Zahnräder
Tja... hättest mal lieber die blaue Pille genommen... ;)

SCNR