[Linux Mint] Selbst compilierte Binary wird nicht ausgeführt

[Metal_Warrior]

Kann es sein, dass du ein 64bit-System ohne Multiarch hast? Da liegen nämlich die Libraries aus historischen Gründen oft noch rein unter /lib64, während die 32bit-Dateien noch unter /lib oder /lib32 hängen. Wenn du jetzt 64bit hast, und kein Multiarch installiert, GCC aber schon vermutet, dass die Libraries immer unter /lib liegen, hast du natürlich ein Ausführungsproblem, wie das Genannte. Falls /lib nicht existiert (bin mir bei Mint nicht so sicher, die nehmen meist ein verhunztes Debian (also Ubuntu) und tackern da dann selber noch rum), kannst du das auch direkt auf /lib64 linken, dann ist dein Problem auch Geschichte. Alternativ einfach die ld-linux-x86-64.so.2 dort rein verlinken.

 

[Rakorium-M]

Was unter ldd /bin/sh steht sieht gut aus - dort liegt der Loader unter Ubuntu/Mint üblicherweise.

Du kannst natürlich einen Symlink von /lib64/ld-linux-x86-64.so.2 auf /lib/ld-linux-x86-64.so.2 setzen - aber das löst das Problem nur für dich, nicht für Andere, die deine Binary bekommen. Was der Compiler genau für Probleme hat kann ich dir nicht sagen - du könntest höchstens mal versuchen dein Projekt außerhalb von Code::Blocks auf der Kommandozeile zu bauen.

 

[Kenobi van Gin]

Kann es sein, dass du ein 64bit-System ohne Multiarch hast?

Keine Ahnung Wie findet man das raus?

aber das löst das Problem nur für dich, nicht für Andere, die deine Binary bekommen.

Andere (namentlich mein Bekannter) scheinen ja das Problem gar nicht zu haben Ich dachte auch eigentlich immer, dass eben Librarys unter Linux (anders als bei Windows) normalerweise dynamisch gelinkt werden, um die Portabilität auf andere Distributionen zu gewährleisten. (Naja, außerdem spart es natürlich Speicherplatz.) Darum dachte ich jetzt, dass bei mir einfach irgendwas fehlt.

Ich habe auch Mint eigentlich nur genommen, weil ich mal irgendwo gelesen hatte, dass das für Windows-Umsteiger ganz nett sein soll. Hatte aber auch schonmal andere Distributionen. Wenn ihr einen Vorschlag für eine "bessere" Distri habt, bin ich da auch offen

 

[Metal_Warrior]

@Kenobi van Gin: Wenn du das grad nicht weißt, und auch kein Skype oder Steam installiert hast, hast du kein Multiarch installiert.

Libraries werden unter Linux üblicherweise auch dynamisch gelinkt, aber wenn dein Compiler dir natürlich ne 32bit-Anwendung rauswirft, und dein System das nicht unterstützt, dann gehts halt erstmal nicht. Oder eben umgekehrt.

Bessere Distro: Debian. Warum? Stabil, stabil, stabil, und die Mutter von Ubuntu und Mint. Oder, um es böse auszudrücken: Nicht verfrickelt von Leuten, für die "Neu" generell ein Synonym für "Besser" ist, und die lieber was kaputt machen, als "alt" zu verwenden.

 

[Kenobi van Gin]

@Kenobi van Gin: Wenn du das grad nicht weißt, und auch kein Skype oder Steam installiert hast, hast du kein Multiarch installiert.

Mhm, ich weiß nicht, dass ich ein Multiarch installiert habe, Skype habe ich allerdings drauf...

wenn dein Compiler dir natürlich ne 32bit-Anwendung rauswirft, und dein System das nicht unterstützt, dann gehts halt erstmal nicht. Oder eben umgekehrt.

Ist das etwa nicht so wie bei Win, dass 64bit-Systeme zumindest in der Regel auch 32bit-Executables unterstützen? Das hieße also, ich muss, egal als was ich es compiliere (32 oder 64bit), immer damit rechnen, dass die jeweils andere Gruppe mein Programm nicht ausführen kann? Das ist ja unpraktisch...

Bessere Distro: Debian. [...]

Okay, vielleicht gucke ich mir das mal an. Bin bislang noch nicht so gesettlet, dass ich nicht mehr wechseln könnte.

 

[Metal_Warrior]

@Kenobi van Gin: Wenn du Skype drauf hast, müsstest du auch ein Verzeichnis /lib32 haben. Skype kann (zumindest solange sie da nix geändert haben) nur mit den 32bit-Versionen von Pulseaudio was anfangen.

Nein, Linux ist nicht so wie Windows, ein 64bit-System nutzt nur 64bit-Anwendungen. Wenn du 32bit haben willst, kannst du dir die entsprechenden Libraries aber nachinstallieren, dann hast du ein sog. Multiarch-System. Eigentlich ist das nicht unpraktisch, sondern vielmehr platzsparend, weil wozu solltest du die 32bit-Libraries installiert haben, wenn du sie nie nutzt? Bei Windows sind sie installiert, deshalb ist das auch so bloated. Wenn du mal über die komplette Paketverwaltung von Linux nachdenkst, macht das auch nur Sinn: Es werden ja schließlich immer nur die Pakete installiert, die als Abhängigkeit definiert wurden...

Warte mit Debian mal, bis die v10 raus ist. Dürfte nur noch ein paar Wochen dauern, dann musst du nicht gleich wieder ein Dist-Upgrade machen (auch wenn das unproblematisch wäre).

 

[Rakorium-M]

Welche Architekturen dein System (theoretisch) unterstützt kannst du dir mit [kw]echo /lib/*/libc-*.so[/kw] anzeigen lassen. [kw]i386[/kw] ist dabei 32-bit, [kw]x86_64[/kw] ist 64-bit.

Dass Mint generell damit ein Problem hat würde ich ausschließen - nutze selber 19.1 und hatte solche Probleme noch nie. Und ich hab schon ne Menge Compiler damit durch, und noch mehr Projekte compiliert. Ändert aber nix dran dass Debian ebenfalls ein gutes System ist.

Ich hab mal nachverfolgt wo der Pfad herkommt: Der Compiler (in dem Fall gcc) bestimmt den Linker-Pfad - und übergibt ihn mit [kw]-dynamic-linker /lib64/ld-linux-x86-64.so.2[/kw] an [kw]ld[/kw]. Das heißt in deinem Fall: Entweder ist dein System-Compiler kaputtkonfiguriert, oder irgendwo in deinen Projekt-Einstellungen wird der Pfad überschrieben.

 

[Kenobi van Gin]

Ziemlich nervig jedenfalls. Auf der anderen Seite lerne ich natürlich so vielleicht noch ein bisschen was über die technischen Hintergründe und das OS
Im Anhang auf Wunsch mal die beiden Projektdateien zum Experimentieren. Vielleicht kannst du ja damit was anfangen.

 

[Rakorium-M]

Erster schneller Test: Compiliert korrekt und funktioniert (Mint 19.1, 7.4, CodeBlocks 16.1, alles aus den Repos). Es bleibt spannend.

 

[braegler]

Also früher (Debian 7) hatte ich die 32bit Libraries mit

dpkg --add-architecture i386
apt-get update
apt-get install libc6-i386

aufgebügelt.

Warte mit Debian mal, bis die v10 raus ist. Dürfte nur noch ein paar Wochen dauern, dann musst du nicht gleich wieder ein Dist-Upgrade machen (auch wenn das unproblematisch wäre).

Das mit dem unproblematisch kann ich bestätigen.
Erst vor einigen Wochen eine Mühle von Squeeze über Wheezy und Jessie nach Stretch upgegradet. Nur der Umstieg auf systemd hat minimalste Handarbeit gefordert, ansonsten nur die bekannte Schleife "Sourcen anpassen, apt* update, apt* upgrade, apt* dist-upgrade, reboot"

 

[Kenobi van Gin]

(Mint 19.1, 7.4, CodeBlocks 16.1, alles aus den Repos)

Als ich nach Code::Blocks für Linux gesucht habe, habe ich mich zunächst gewundert, dass es dort nur bis Version 16.1 geht, wo die Windows-Version doch bei 17.02 liegt. Außerdem hat diese Code::Blocks-Version (genauer: der Editor) ein bestimmtes Verhalten, das mir unter Windows sehr gut gefällt, nicht gehabt. Also habe ich weiter gesucht und (vermutlich in einem anderen Repository) eine flathub-Version 17.02 für Linux gefunden und die installiert. Das gewünschte Verhalten tritt hier zwar leider immer noch nicht auf, aber so hatte ich zumindest die aktuellste Version. Nun hatte ich auch schon im Verdacht, ob das mit der Problematik zu tun hat.

Das wiederum ist auch ein Ding, das ich nicht verstehe. Ich habe jetzt schon bei mehreren Programmen (u.a. auch bei NetBeans) verschiedene Versionen im Anwendungsmanager gefunden und konnte auf den ersten Blick nicht sehen, wo da der Unterschied liegen soll, außer dass manche einige Bewertungen haben und andere keine einzige

 

[Shodan]

CodeBlocks 16.1, alles aus den Repos

Achtung: Die Software hat keinen Maintainer unter Debian und Ubuntu.

Das wiederum ist auch ein Ding, das ich nicht verstehe. Ich habe jetzt schon bei mehreren Programmen (u.a. auch bei NetBeans) verschiedene Versionen im Anwendungsmanager gefunden und konnte auf den ersten Blick nicht sehen, wo da der Unterschied liegen soll, außer dass manche einige Bewertungen haben und andere keine einzige

Sieh dir das Flatpack Repo an:

You do not have permission to view link please Anmelden or Registrieren

(Findest du unter "publisher" in der Description des Pakets.)
Das sind nur ein paar Metadaten, die das Framework anweisen modular benötigten Code nachzuladen.

Davon kann es mehrere geben und dadurch dann verschiedene Versionen von verschiedenen Publishern mit unterschiedlichen Bewertungen.

 

[Metal_Warrior]

Das sind nur ein paar Metadaten, die das Framework anweisen modular benötigten Code nachzuladen.

Nur, dass ich das richtig verstehe: Man läd zur Laufzeit oder zur Compiling-Zeit irgendwelchen Schlonz aus dem Internet nach, von Leuten, die man nicht kennt, von Repos, die jeder Hanswurst aufsetzen kann, ohne dass das Leute überprüft haben...

Wenn jemand mir sagen würde, ich soll solche Software hier auf dem Server laufen lassen, würdet ihr dem Forum noch vertrauen? Also ich nicht. Und da wundert mich auch gar nicht mehr, dass jeden Tag zig Server "Datenreichtum" aufweisen können. Wem diese Vorgehensweise beim Programmieren eingefallen ist, sollte man den Kopf abhacken und als Warnung an die Haustür von jeder Softwareklitsche nageln.

 

[Rakorium-M]

Also habe ich weiter gesucht und (vermutlich in einem anderen Repository) eine flathub-Version 17.02 für Linux gefunden und die installiert.

Dann macht alles Sinn. Flatpak-Anwendungen bringen praktisch ihr eigenes Mini-Betriebssystem mit (sämtliche Libraries inklusive Loader), ordentlich verpackt in einem Container. Dadurch läuft die selbe Flatpak-Anwendung auf sämtlichen Linux-Systemen, egal welche Libraries etc. auf dem Host installiert sind. Die Technik dahinter ist die gleiche wie bei den aktuellen Container-Lösungen (Docker etc).
CodeBlocks (inkl. dem verwendeten Compiler) setzt also nicht auf deinem Betriebssystem auf, sondern auf den mitgebrachten Libraries. Deine Anwendung wird also gegen den Flatpak-Container compiliert, nicht gegen dein eigentliches Betriebssystem. Im Container liegt der Loader an einer anderen Adresse - deshalb sucht die fertige Binary den auch woanders.
Lösen kannst du das wahrscheinlich relativ einfach, indem du die fertige Binary von Hand auf der Kommandozeile erzeugst. Falls in einem der Projektordner später eine Datei namens [kw]Makefile[/kw] liegt, kannst du in diesem Ordner [kw]make clean && make[/kw] in die Konsole eingeben.

Das wiederum ist auch ein Ding, das ich nicht verstehe. Ich habe jetzt schon bei mehreren Programmen (u.a. auch bei NetBeans) verschiedene Versionen im Anwendungsmanager gefunden und konnte auf den ersten Blick nicht sehen, wo da der Unterschied liegen soll, außer dass manche einige Bewertungen haben und andere keine einzige

Die Anwendungsverwaltung findet eben die "native" CodeBlocks-Version aus den Ubuntu-Repos und das CodeBlocks-Flatpak.

@Metal_Warrior Ist eben das gleiche Konzept wie bei Docker bzw. den PPAs bzw. Fremdquellen im Allgemeinen. Sobald die von der Distribution angebotene Auswahl für einen Anwendungszweck nicht mehr ausreicht landet man immer in dieser Zwickmühle. Flatpak ist da wenigstens so nett und zeigt dir auf Github, welche Dateien bezogen werden. Im Fall von CodeBlocks sieht das für mich sogar vertretbar aus. Auf nem Server wär ich damit aber auch vorsichtig - zumal sich Flatpak an Endanwender richtet.

 

[Kenobi van Gin]

...oder andersrum könnte ich auch einfach wieder auf die Version aus dem offiziellen Repo umsteigen? Dann müsste es auch gehen?
Finds nur dämlich, dass es dann eben für Linux keine offizielle Version 17.02 gibt

 

[theSplit]

You do not have permission to view link please Anmelden or Registrieren

Kannst du kein Paket von

You do not have permission to view link please Anmelden or Registrieren

installieren?

Okay, das Updaten geht dann nur von Hand, aber ist meiner Meinung nach die besten Option wenn du eine aktuellere Version installieren willst die eventuell nicht in den Repos ist.

 

[Rakorium-M]

Die offizielle Version müsste funktionieren, die Debian-Pakete von theSplit müssten es auch tun.

 

[Kenobi van Gin]

Vielen Dank für eure ganzen Hinweise schonmal. Habe mir heute von der Code::Blocks-Seite das Archiv mit den aktuellen Binarys runtergeladen. Jetzt muss ich nur noch rausfinden, wie ich daraus ein Installationsskript mache Aber das schaffe ich
Jedenfalls habe ich durch diesen Thread schon wieder eine ganze Menge über Betriebssysteme im Allgemeinen und Linux im Besonderen gelernt. Danke dafür

 

[theSplit]

You do not have permission to view link please Anmelden or Registrieren

Auch wenn du es sicherlich ohne weitere Hilfe schaffst, ist es dreist [kw]dpkg[/kw] in den Raum zu werfen?

 

[Kenobi van Gin]

Ja Ich würde mir sonst erstmal mit man und make versuchen zu helfen? Falls nicht, komme ich auf deinen Einwand zurück