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.
:
Bearbeitet durch User
"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.
Dann zeig doch mal, wie du den gcc aufrufst. Oliver
> 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.
:
Bearbeitet durch User
Klaus F. schrieb: > Option "-shared" das > Dateiformat "Gemeinsame Bibliothek" bzw. "shared library" und ich vermag > es auch durch keine mir bekannte Option abzustellen. Das Gegenstück müsste eigentlich "-static" sein: - https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html
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 :-)
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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?
1.) $ gcc -Wall -o Programmname Code.c -lm -> 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 -> 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.) $ clang -Wall -o Programmname Code.c -lm -> 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
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?
:
Bearbeitet durch User
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.
Angehängte Dateien:
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?
Könntest Du statt der nichtssagenden Bezeichnungen irgendwelcher Dateimanager nicht einfach die Ausgabe von
1 | ls -al |
posten?
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.
Noch zur Frage von Harald: ls -al bringt leider nicht viel, wie die folgende Ausgabe verdeutlicht:
1 | $ ls -al |
2 | insgesamt 2 |
3 | -rw-r--r-- 1 21627 Mai 3 2012 Code.c |
4 | -rwxr-xr-x 1 34840 Apr 19 16:31 Programmname |
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 |
(Wobei ich bei dir auch "pie executable" sehe, also doch die Dateimanager.)
Worin könnten mögliche Nachteile bestehen bei Verwendung von $ gcc -Wall -o Programmname Code.c -lm -no-pie anstatt $ gcc -Wall -o Programmname Code.c -lm und weshalb greift clang offensichtlich nicht auf pie zurück?
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.
Bei mir kommt pcmanfm zum Einsatz. Von daher sollte der Startklick eigentlich funktionieren.
Jörg W. schrieb: > d.h. da steht eindeutig "executable" statt nur "shared object" unter Lt dem hier: Beitrag "Re: Unterschiedliche Typen der nach dem Compilerlauf erzeugten Programmdateien von gcc und clang" steht bei TO da auch executable, nur der grafische Dateimanager ist anderer Meinung. Oliver
:
Bearbeitet durch User
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
Merkwürdig, bei mir fragt pcmanfm brav nach... (und erkennt es auch als executable)
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
Beitrag #7398013 wurde vom Autor gelöscht.
Beitrag #7398022 wurde vom Autor gelöscht.
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.
Ich nutze Devuan (release daedalus). Die entsprechenden Pakete sind eigentlich die selben, wie in Debian Bookworm.
1 | $ lsb_release -a |
2 | No LSB modules are available. |
3 | Distributor ID: Devuan |
4 | Description: Devuan GNU/Linux 5 (daedalus/ceres) |
5 | Release: 5 |
6 | Codename: daedalus ceres |
7 | $ dpkg-query -l | grep ' gcc \|pcmanfm' |
8 | ii gcc 4:12.2.0-3 amd64 GNU C compiler |
9 | ii pcmanfm 1.3.2-1 amd64 extremely fast and lightweight file manager |
Sollte zwar eigentlich nicht daran liegen.
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.
Vielleicht gibt es ja beispielsweise auf der Basis von
1 | $ xdg-mime query filetype ~/pfad/Programmname |
2 | application/x-sharedlib |
3 | $ xdg-mime query default application/x-sharedlib |
Möglichkeiten, den Dateimanager, wie pcmanfm, zu überlisten bzw. zum Start des pie-executables durch Anklicken im Dateimanager zu bewegen?
:
Bearbeitet durch User
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:
1 | dpa@dragonfly:~/x$ grep -r application/x-sharedlib /usr/share/mime/ |
2 | /usr/share/mime/types:application/x-sharedlib |
3 | grep: /usr/share/mime/magic: binary file matches |
4 | /usr/share/mime/packages/freedesktop.org.xml: <mime-type type="application/x-sharedlib"> |
5 | /usr/share/mime/application/x-sharedlib.xml:<mime-type xmlns="http://www.freedesktop.org/standards/shared-mime-info" type="application/x-sharedlib"> |
6 | /usr/share/mime/globs:application/x-sharedlib:*.so.[0-9]* |
7 | /usr/share/mime/globs:application/x-sharedlib:*.so |
8 | grep: /usr/share/mime/mime.cache: binary file matches |
9 | /usr/share/mime/globs2:60:application/x-sharedlib:*.so.[0-9]* |
10 | /usr/share/mime/globs2:50:application/x-sharedlib:*.so |
11 | dpa@dragonfly:~/x$ |
Aber selbst dann, ein Dateimanager sollte eigentlich nicht danach gehen...
Meine diesbezügliche Ausgabe sieht so aus: $ grep -r application/x-sharedlib /usr/share/mime/ /usr/share/mime/globs2:50:application/x-sharedlib:*.dll /usr/share/mime/globs2:50:application/x-sharedlib:*.so.[0-9].* /usr/share/mime/globs2:50:application/x-sharedlib:*.so /usr/share/mime/globs2:50:application/x-sharedlib:*.so.[0-9] Übereinstimmungen in Binärdatei /usr/share/mime/mime.cache /usr/share/mime/globs:application/x-sharedlib:*.dll /usr/share/mime/globs:application/x-sharedlib:*.so.[0-9].* /usr/share/mime/globs:application/x-sharedlib:*.so /usr/share/mime/globs:application/x-sharedlib:*.so.[0-9] /usr/share/mime/types:application/x-sharedlib /usr/share/mime/packages/libfm.xml: <mime-type type="application/x-sharedlib"> /usr/share/mime/packages/freedesktop.org.xml: <mime-type type="application/x-sharedlib"> Übereinstimmungen in Binärdatei /usr/share/mime/magic /usr/share/mime/application/x-sharedlib.xml:<mime-type xmlns="http://www.freedesktop.org/standards/shared-mime-info"; type="application/x-sharedlib">
Das sieht eigentlich unauffällig aus. Eventuell könnte man noch nachsehen, ob unter /usr/local/share/mime oder ~/.local/share/mime/ etwas ist.
Sowohl unter ~/.local/share/ als auch /usr/local/share/ findet sich kein Verzeichnis /mime.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.