In Debian (V.10) erzeugt jeder Comilerlauf von gcc regelmässig
ausführende Dateien (Programme) mit der Typenbezeichnung bzw.
-beschreibung "Gemeinsame Bibliothek", womit sich allerdings das Problem
verbindet, dass ein Anklicken der betreffenden Datei trotz sämtlich
erteilter Ausführungsrechte nicht zum Start im Dateimanager führt.
Hingegen liess sich noch vor Jahren mit gcc und gleichem C-Code direkt
ausführende Dateien mit der Typenbezeichnung bzw. -beschreibung
"Programm" generieren, deren Start selbstverständlich direkt im
Dateimanager durch Anklicken gelang und zwar auf gleiche Weise wie es
sich jetzt noch mit dem C-Compiler clang unter Debian vollziehen lässt.
Davon unabhängig lassen sich im Terminal alle vorgeannten Resultate mit
./cprogramm starten, aber vielfach bedarf es in meinen Anwendungsfällen
des explizit direkten Programmstartes über den jeweiligen Dateimanager.
Von daher freue ich mich um so mehr über Eure Feedbacks und Erklärungen
bzw. ggf. Abhilfemöglichkeiten des vorgeschilderten Problems.
"Gemeinsame Bibliothek" soll wohl ein "shared library" sein (übliche
Endung .so, aber nicht zwingend). Damit der Compiler die erzeugt, musst
du die Option "-shared" angegeben haben. Warum machst du das, wenn du
sie garnicht haben willst.
Danke für Deine rasche Antwort. Bedauerlicherweise erzeugt gcc seit
einigen Jahren automatisch ohne Eingaber der Option "-shared" das
Dateiformat "Gemeinsame Bibliothek" bzw. "shared library" und ich vermag
es auch durch keine mir bekannte Option abzustellen.
> Bedauerlicherweise erzeugt gcc seit einigen Jahren automatisch ohne> Eingaber der Option "-shared" das Dateiformat "Gemeinsame Bibliothek"> bzw. "shared library"
Der gcc von Hause aus mit Sicherheit nicht. Das muss irgendeine kaputte
Einstellung bei dir sein.
> und ich vermag es auch durch keine mir bekannte Option abzustellen.
Weil das Erstellen von Executables der Default ist. Afaik gibt es keine
Option, ein vorhandes "-shared" rückgängig zu machen.
Zeig mal deine Kommandozeile, mit der du Übersetzt.
Gerne:
$ gcc -Wall -o Programmname Code.c -lm
wobei die damit entstehende ausführende Datei "Programmname" die
Typenbezeichnung bzw. -beschreibung "Gemeinsame Bibliothek" trägt im
Gegensatz zum Aufruf
$ clang -Wall -o Programmname Code.c -lm
und hieraus die ausführende Datei "Programmname" mit der
Typenbezeichnung bzw. -beschreibung "Programm" resultiert, die sich im
Dateimanager starten lässt, so wie vor Jahren auch mit gcc.
Vielen Dank für Deinen wie auch Eure Hinweise auf dem Weg zum Ziel.
In der Tat es funktioniert beispielsweise mit folgender Sequenz:
$ gcc -Wall -o Programmname Code.c -lm -static
Daraus resultiert die ausführende Datei "Programmname" mit der
Typenbezeichnung bzw. -beschreibung "Programm", die sich tatsächlich im
Dateimanager starten lässt.
Habt Tausenddank :-)
Weiss vielleicht jemand noch etwas in diesem Zusammenhang zur Situation
um den Compiler clang im Vergleich zu gcc mit der Option "-static" zu
berichten, da clang ja von vornherein ausführende Dateien mit der
Typenbezeichnung bzw. -beschreibung "Programm" erzeugt, die sich durch
Anklicken im Dateimanager direkt starten lassen.
Schau mal nach, wie groß die Programmname jeweils sind. Normalerweise
will man -static nicht, weil die Programme riesig werden. Was sagt "file
Programmname" zu den drei Varianten?
Probier mal -no-pie statt -static. Aber das kann nur eine Notlösung
sein. Der Dateimanager müsste lernen, dass neuerdings auch solche
Dateien ausführbar sind.
Vielen Dank für Deinen ausgezeichnenten Tipp.
Bereits vorgestern probierte ich mit dieser Option, also -no-pie, zu
arbeiten leider erfolglos, da ich sie möglicherweise an der falschen
Stelle platzierte anstatt sie hinten anzufügen.
Nunmehr funktioniert es, wie folgende Zeilen zeigen:
$ gcc -Wall -o Programmname Code.c -lm -no-pie
-> Programmname, Programm, 33.8 KiB
$ file Programmname
Programmname: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for
GNU/Linux 3.2.0, BuildID[sha1]=ec9be72848e9f3c570ff22e7f984b0e3ec5b80ce,
not stripped
Jetzt dürften also die Ergebnisse von "clang" und "gcc zusammen mit
-no-pie" identisch sein, oder?
Klaus F. schrieb:> 1.)> $ gcc -Wall -o Programmname Code.c -lm> -> Programmname, Gemeinsame Bibliothek, 34 KiB> $ file Programmname
Wer oder was zeigte denn das -> "Programmname, Gemeinsame Bibliothek, 34
KiB" an?
> Programmname: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV),> dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for> GNU/Linux 3.2.0, BuildID[sha1]=0bb952650699494343de6ea24ada11ba4d15f5f8,> not stripped
Und wo ist jetzt das Problem?
Oliver
Debian 10 hat zwar noch LTS Support bis Mitte nächstes Jahr, ist aber
trotzdem nicht besonders aktuell. Deswegen hat es Schwierigkeiten, PIE
Executables von Shared Libraries zu unterscheiden und der Gnome
Dateimanager Nautilus weigert sich, letztere zu starten (tatsächlich
sind die Gnome-Designer sogar der Ansicht, ein Dateimanager solle
überhaupt keine Executables starten und haben sich deswegen lange
geweigert, das überhaupt als Fehler anzuerkennen).
Falls das noch die Original 10.0-Installation von Debian ist, hilft evt.
ein Upgrade auf 10.13 (die letzte Debian 10). Ich weiss es nicht, aber
es könnte sein, dass da was repariert ist.
Anknüpfend an die dankenswerten jüngsten Ausführungen von Oliver und
Markus sei auf die angehängten Screenshots verwiesen.
-> "Programmname, Gemeinsame Bibliothek, 34 KiB" steht für die
entsprechenden im LXDE-Dateimanager, pcmanfm, ersichtlichen Angaben.
Möglicherweise liegt das Problem nicht nur bei Gnome, sondern
möglicherweise noch tiefer im System, da auch LXDE davon betroffen zu
sein scheint?
Klaus F. schrieb:> Möglicherweise liegt das Problem nicht nur bei Gnome, sondern> möglicherweise noch tiefer im System, da auch LXDE davon betroffen zu> sein scheint?
Das Problem liegt in den Dateimanagern selbst.
Die Dateien sind ja ordnungsgemäß ausführbar: wenn du auf die
Kommandozeile gehst, kannst du sie mit
1
./Programmname
starten. GCC baut halt mittlerweile standardmäßig ein "position
independant executable" (PIE), und die Dateimanager begreifen nicht,
dass selbiges tatsächlich eine ausführbare Datei ist. Die Schuld liegt
also bei denen.
Jörg W. schrieb:> Das Problem liegt in den Dateimanagern selbst.
Möglicherweise auch an der Datenbank von "file". Wenn ich das gleiche
unter FreeBSD mache und ein PIE erzeuge, sagt mir file:
1
% file Programmname
2
Programmname: ELF 64-bit LSB pie executable, x86-64, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 12.3 (1203505), FreeBSD-style, with debug_info, not stripped
d.h. da steht eindeutig "executable" statt nur "shared object" unter
Linux:
1
$ file Programmname
2
Programmname: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=3ae102fd1ede886ab7595a2d8d41ee37d3cf8719, for GNU/Linux 3.2.0, not stripped
Im Grunde ist es ganz simple. Hat die Datei das Executable Flag gesetzt,
ist sie ausführbar. Der Dateimanager sollte dann beim anklicken das Ding
ausführen, oder nachfragen. Der Dateityp ist da völlig egal. Wenn dein
Dateimanager das nicht tut, dann schmeiss ihn weg, und nimm einen
anderen. Thunar, dolphin, pcmanfm, nautilus, ... Gibt ja viel Auswahl.
Klaus F. schrieb:> weshalb greift clang offensichtlich nicht auf pie zurück?
GCC bei mir (FreeBSD) macht es auch nicht von sich aus.
Keine Ahnung, warum dem Linux-GCC das jemand als Default beigebogen hat.
Da müsstest du diejenigen fragen, die diese Entscheidung getroffen haben
…
Abhandlungen dazu kannst du dir ergoogeln, hier bspw.:
https://docs.oracle.com/cd/E26505_01/html/E26506/glmqp.html
Vielen Dank Jörg für Deine überaus hilfreichen wie klärenden Beiträge in
der Sache sowie natürlich auch allen anderen Teilnehmern.
Basierend darauf seien der Übersicht willen an dieser Stelle nochmals
die bis hierher wohl wesentlichen diesem Thread zugrundeliegenden
Befehlsvarianten bzw. -welten in der mir von 1.) nach 4.) aufsteigend
bevorzugten Reihenfolge aus Gründen der Start- und Ausführbedingungen
und darüber hinausgehenden Kriterien wie beispielsweise
Speicherplatzbedarf, wonach 2.) eigentlich vollkommen ausscheidet,
angegeben:
1.)
$ gcc -Wall -o Programmname Code.c -lm
-> Angaben im Dateimanger pcmanfm: Programmname, Gemeinsame Bibliothek,
34 KiB
$ file Programmname
Programmname: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV),
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for
GNU/Linux 3.2.0, BuildID[sha1]=0bb952650699494343de6ea24ada11ba4d15f5f8,
not stripped
2.)
$ gcc -Wall -o Programmname Code.c -lm -static
-> Angaben im Dateimanger pcmanfm: Programmname, Programm, 1.4 MiB
$ file Programmname
Programmname: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux),
statically linked, for GNU/Linux 3.2.0,
BuildID[sha1]=8b4f050b4dcb3721811014afbf1bc5878b76fbd8, not stripped
3.)
$ gcc -Wall -o Programmname Code.c -lm -no-pie
-> Angaben im Dateimanger pcmanfm: Programmname, Programm, 33.8 KiB
$ file Programmname
Programmname: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for
GNU/Linux 3.2.0, BuildID[sha1]=ec9be72848e9f3c570ff22e7f984b0e3ec5b80ce,
not stripped
4.)
$ clang -Wall -o Programmname Code.c -lm
-> Angaben im Dateimanger pcmanfm: Programmname, Programm, 33.9 KiB
$ file Programmname
Programmname: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for
GNU/Linux 3.2.0, BuildID[sha1]=afbc0cb5f3765982b4131181d679f947cff123f7,
not stripped
Auffällig bleibt insbesondere die Gemeinsamkeit der Ausgaben von 3.) und
4.), die immer in "speichersparenden" und "aus dem Dateimanager
startbaren" Programmen münden, was sich für bestimmte Anwendungsfälle
als unverzichtbar erweist, speziell wenn es darum geht, dem Endanwender
ein direkt mittels der grafischen Benutzerschnittstelle anwählbares
Programm zur Verfügung zu stellen und der Endanwender sich nicht
zugleich mit Programmaufrufen aus dem Terminal heraus aufhalten oder
beschäftigen möchte bzw. will.
Daniel darf ich Dich höflich nach Deiner Distributuion fragen? Ggf.
starten die mit gcc generierten Programme durch Anklicken im
Dateimanager unter Ubuntu aber nicht unter Debian.
Klaus F. schrieb:> Anklicken der betreffenden Datei trotz sämtlich> erteilter Ausführungsrechte nicht zum Start im Dateimanager führt
Im aktuellen Debian Stable funktioniert das prima, kommt halt auf den
Dateimanager an - auf meinem Desktop ist es der mc (im Terminal).
Etwas Hintergrund: Position-Independent-Executables (PIE) werden für
Address-Space-Layout-Randomization (ASLR) gebraucht. ASLR ist eine
Methode, um Exploits das Leben etwas schwerer zu machen, indem das
Programm bei jedem Start an andere Adressen geladen wird. Das geht nur,
wenn dem Programm seine Lage im Speicher egal ist - das macht die
PIE-Compiler-Option. PIE braucht etwas mehr Speicher, ist etwas
langsamer als regulärer Code und muß beim Laden zusätzlich relokiert
werden.
Debian-Hardened (eine auf Sicherheit optimierte Version von Debian) hat
PIE vor ein paar Jahren als Default für alle Programme eingeführt. U.A.
wurde auch der gcc angepasst, dass er standardmäßig solche Executables
erstellt. Es scheint, dass das reguläre Debian das igendwann übernommen
hat.
Ich bin kein Fan von PIE, auf meinen Systemen ist ASLR abgeschaltet.
Das Problem von Klaus ist ausschließlich der Dateimanager, der bei PIEs
einen falschen Dateityp erkennt und entspr falsche Aktionen assoziiert.
Der sinnvollste Fix wäre, den Dateimanager zu reparieren.
Non-PIE-Programme zu erstellen ist ein Work-Around, der allerdings die
Systemphilosophie unterwandert. Eine Alternative wäre z.B. ein
Shell-Script, das der Dateimanager erkennt und welches dann das
Executable aufruft:
1
#!/bin/sh
2
exec Programmname "$@"# Programmname ggf mit Pfad
Einige Dateimanager bieten auch kleine App-Links an, mit denen man dem
Programmen u.a. Icons zuordnen kann aber auch den eigentlichen Aufruf
hinterlegt.
Bei mir sagt das application/x-executable.
Suche mal nach "grep -r application/x-sharedlib /usr/share/mime/".
Eventuell ist da was das matcht. Bei mir ist das hier drin:
Thread beobachten
Seitenaufteilung abschalten