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.
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.
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.
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:
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
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.
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.
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.
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.
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.
