• Hallo liebe Userinnen und User,

    nach bereits längeren Planungen und Vorbereitungen sind wir nun von vBulletin auf Xenforo umgestiegen. Die Umstellung musste leider aufgrund der Serverprobleme der letzten Tage notgedrungen vorverlegt werden. Das neue Forum ist soweit voll funktionsfähig, allerdings sind noch nicht alle der gewohnten Funktionen vorhanden. Nach Möglichkeit werden wir sie in den nächsten Wochen nachrüsten. Dafür sollte es nun einige der Probleme lösen, die wir in den letzten Tagen, Wochen und Monaten hatten. Auch der Server ist nun potenter als bei unserem alten Hoster, wodurch wir nun langfristig den Tank mit Bytes vollgetankt haben.

    Anfangs mag die neue Boardsoftware etwas ungewohnt sein, aber man findet sich recht schnell ein. Wir wissen, dass ihr alle Gewohnheitstiere seid, aber gebt dem neuen Board eine Chance.
    Sollte etwas der neuen oder auch gewohnten Funktionen unklar sein, könnt ihr den "Wo issn da der Button zu"-Thread im Feedback nutzen. Bugs meldet ihr bitte im Bugtracker, es wird sicher welche geben die uns noch nicht aufgefallen sind. Ich werde das dann versuchen, halbwegs im Startbeitrag übersichtlich zu halten, was an Arbeit noch aussteht.

    Neu ist, dass die Boardsoftware deutlich besser für Mobiltelefone und diverse Endgeräte geeignet ist und nun auch im mobilen Style alle Funktionen verfügbar sind. Am Desktop findet ihr oben rechts sowohl den Umschalter zwischen hellem und dunklem Style. Am Handy ist der Hell-/Dunkelschalter am Ende der Seite. Damit sollte zukünftig jeder sein Board so konfigurieren können, wie es ihm am liebsten ist.


    Die restlichen Funktionen sollten eigentlich soweit wie gewohnt funktionieren. Einfach mal ein wenig damit spielen oder bei Unklarheiten im Thread nachfragen. Viel Spaß im ngb 2.0.

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

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
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

NGBler

Registriert
14 Juli 2013
Beiträge
413
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

Brillenschlange

Registriert
14 Juli 2013
Beiträge
3.620
Ort
.\
  • Thread Starter Thread Starter
  • #23
Kann es sein, dass du ein 64bit-System ohne Multiarch hast?
Keine Ahnung :D 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 :unknown: 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 :D
 

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
@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

Brillenschlange

Registriert
14 Juli 2013
Beiträge
3.620
Ort
.\
  • Thread Starter Thread Starter
  • #25
@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

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
@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

NGBler

Registriert
14 Juli 2013
Beiträge
413
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

Brillenschlange

Registriert
14 Juli 2013
Beiträge
3.620
Ort
.\
  • Thread Starter Thread Starter
  • #28
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 :D
Im Anhang auf Wunsch mal die beiden Projektdateien zum Experimentieren. Vielleicht kannst du ja damit was anfangen.
 

Anhänge

  • 4wins Bot.tar.gz
    6 KB · Aufrufe: 486

Rakorium-M

NGBler

Registriert
14 Juli 2013
Beiträge
413
Erster schneller Test: Compiliert korrekt und funktioniert (Mint 19.1, 7.4, CodeBlocks 16.1, alles aus den Repos). Es bleibt spannend.
 

braegler

Aktiver NGBler

Registriert
14 Juli 2013
Beiträge
896
Also früher (Debian 7) hatte ich die 32bit Libraries mit
Code:
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

Brillenschlange

Registriert
14 Juli 2013
Beiträge
3.620
Ort
.\
  • Thread Starter Thread Starter
  • #31
(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 :unknown:
 

Shodan

runs on biochips

Registriert
14 Juli 2013
Beiträge
661
Ort
Citadel Station
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 :unknown:
Sieh dir das Flatpack Repo an: https://github.com/flathub/org.codeblocks.codeblocks
(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.
 
Zuletzt bearbeitet:

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
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

NGBler

Registriert
14 Juli 2013
Beiträge
413
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 :unknown:
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

Brillenschlange

Registriert
14 Juli 2013
Beiträge
3.620
Ort
.\
  • Thread Starter Thread Starter
  • #35
...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 :confused:
 

theSplit

1998
Veteran Barkeeper

Registriert
3 Aug. 2014
Beiträge
28.560
@Kenobi van Gin: Kannst du kein Paket von hier 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

NGBler

Registriert
14 Juli 2013
Beiträge
413
Die offizielle Version müsste funktionieren, die Debian-Pakete von theSplit müssten es auch tun.
 

Kenobi van Gin

Brillenschlange

Registriert
14 Juli 2013
Beiträge
3.620
Ort
.\
  • Thread Starter Thread Starter
  • #38
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 :D Aber das schaffe ich :T
Jedenfalls habe ich durch diesen Thread schon wieder eine ganze Menge über Betriebssysteme im Allgemeinen und Linux im Besonderen gelernt. Danke dafür :beer:
 

Kenobi van Gin

Brillenschlange

Registriert
14 Juli 2013
Beiträge
3.620
Ort
.\
  • Thread Starter Thread Starter
  • #40
Ja :p Ich würde mir sonst erstmal mit man und make versuchen zu helfen? Falls nicht, komme ich auf deinen Einwand zurück :D
 
Zuletzt bearbeitet:
Oben