Ich benötige etwas Starthilfe zum Programmieren (C/C++)

Dakuan · 11. Jan

Das klingt jetzt schlimmer als es ist. Ich habe Archlinux jetzt gerade halbwegs zum laufen bekommen, und möchte jetzt meine selbstgestrikten Programme auch unter Arch zum laufen bekommen.

Bei Debian/Ubuntu war der Start recht einfach. Da war mit "build-essential" fast schon alles erledigt. Aber hier bin ich verunsichert, weil es hier kein "rundum-sorglos" Paket gibt. Was ich bisher bewusst verwendet habe:
gcc, gdb, make, nemiver & geany
Da mein bevorzugtes Toolkit FLTK ist, was ich aus dem Quelltext installieren möchte, benötige ich auch:
autoconf & automake
Muss ich das jetzt alles einzeln installieren und wenn ja, fehlt da dann trotzdem noch etwas?

frostschutz · 11. Jan

es gibt base-devel das ist so ähnlich wie build-essential

ansonsten wirst schon merken wenn was fehlt und installierst es dann

ich nutze base-devel selbst nicht, weil es sudo reinzieht, was für mich nicht mit devel zu tun hat

MMartin-MS · 11. Jan

Dakuan Bei Debian/Ubuntu war der Start recht einfach. Da war mit "build-essential" fast schon alles erledigt. Aber hier bin ich verunsichert, weil es hier kein "rundum-sorglos" Paket gibt.

Doch… der einzige vernünftige Weg ist, sich Installations-Pakete zu erstellen. Dazu erstellst du zuerst wie hier beschrieben eine Entwicklungsgebung zum Bauen der Pakete. Dabei wird alles installiert, was zum Bauen eines Pakets benötigt wird. Was das Paket selber benötigt, wird über Paketabhängigkeiten festgelegt, wobei zwischen Abhängkeiten unterschieden wird, die nur zum Bauen des Pakets oder zur Laufzeit notwendig sind. Alle Schritte, die zum Bauen eines Pakets notwendig sind, werden in einem Skript PKGBUILD festgelegt.

Dakuan Da mein bevorzugtes Toolkit FLTK ist, was ich aus dem Quelltext installieren möchte, benötige ich auch:
autoconf & automake

FLTK gibt es hier als offizielles Paket für die Version 1.3.9, und muss deshalb nicht aus den Quellen gebaut werden, wenn es die noch in der Entwicklung befindliche Version 1.4 sein soll, muss du es selber aus dem AUR bauen. Das Paket wird mit cmake und nicht automake erselltt; sieht man aber auch alles im entsprechenden PKGBUILD.

Da in der Entwicklungsumgebung zum Bauen der Pakete autoconf und automake über die Abhängigkeiten von base-develnachgezoigen wird, stünde es dort auch zur Verfügung.

Dakuan Muss ich das jetzt alles einzeln installieren und wenn ja, fehlt da dann trotzdem noch etwas?

"Nein" und "nein", wenn du es so wie beschrieben machst.

Dakuan · 11. Jan

@ frostschutz ok, dann probiere ich das morgen mal. Mal sehen, wer da alles meckert.
@ Martin-MS Ich will eigentlich (noch) keine kompletten Pakete bauen. Es muss ja erstmal funktionieren. Ich rechne nicht damit, dass alles sofort funktioniert.

FLTK gibt es hier als offizielles Paket für die Version 1.3.9, und muss deshalb nicht aus den Quellen gebaut werden, ...

Ich will, aus historischen Gründen, unbedingt den aktuellen Quelltext haben. Das hängt damit zusammen, dass ich auch schon mal an einem Bugfix beteiligt war. Da wird dann von einem erwartet, dass man den aktuellen Quältext hat. Da wird dann nur eine patch Datei geschickt und man soll dann mitteilen, ob damit das Problem gelöst ist.
Deswegen schalte ich bei der Installation oft auch die "abi-breaking" features frei. Das geht bei normaler Installation nicht. Und ich linke daher auch statisch.

niemand · 12. Jan

Dakuan Ich will, aus historischen Gründen, unbedingt den aktuellen Quelltext haben.

@Martin-MS hat das schon geschrieben, aber es scheint etwas untergegangen zu sein: Da würde sich das AUR anbieten: https://aur.archlinux.org/packages/fltk-git – damit lässt sich mit einem Befehl ein fertiges Paket mit der jeweils aktuellen Version bauen und sauber(!) installieren.

Dakuan Bei Debian/Ubuntu war der Start recht einfach.

Wenn du von Debian und Derivaten kommst: Dort werden die Upstream-Pakete häufig aufgeteilt. Sachen, die nur für das Entwickeln für/mit eine/r Software gebraucht werden, findet man dort meist im software-dev-Paket. Bei Arch gibt es diese Aufteilung in der Regel nicht; wenn man das Paket installiert, hat man im Normalfall auch alles, was man zum Entwickeln braucht. Mich hatte das damals™ etwas irritiert, deswegen der Hinweis an dieser Stelle.

MMartin-MS · 12. Jan

Dakuan Ich will eigentlich (noch) keine kompletten Pakete bauen. Es muss ja erstmal funktionieren. Ich rechne nicht damit, dass alles sofort funktioniert.

Das ist aber der springende Punkt, dass wenn alles sofort funktionieren soll es eben nur so geht. Vor allem: willst du dein gerade frisch installiertes System mit Paketen zumüllen, die du nur für die Entwicklung brauchst und sonst nicht? Willst du alle Pakete, die (nur) dein Entwicklungsprojekt braucht, auf deinem produktiven System installieren? Und nachher wieder de-installieren? Des weiteren wirst du nicht feststellen können, welche Pakete du (und später vielleicht auch andere Benutzer deines Projekts) tatsächlich als Abhängigkeit benötigen, wenn dein Produktivsystem diese Pakete schon installiert hat, aber das Zielsystem unter Umständen nicht. Das Produktiv- und Entwicklungssystem sollte man strikt voneinander trennen, und dazu ist nur ein clean chroot geeignet. Alles andere ist Murks und verursacht nur Frust. Es wird dir auch bei evtl. Problemen keiner helfen können, wenn man über zwei völlig unterschiedliche Entwicklungsumgebungen spricht und deshalb Probleme nicht nachvollziehen kann. Das ist Erfahrung und erleben wir hier (und leider auch im AUR) immer mal wieder.

Dakuan Das hängt damit zusammen, dass ich auch schon mal an einem Bugfix beteiligt war. Da wird dann von einem erwartet, dass man den aktuellen Quältext hat. Da wird dann nur eine patch Datei geschickt und man soll dann mitteilen, ob damit das Problem gelöst ist.

Genau dafür ist das Arch Build System bestens geeignet. Patche werden im PKGBUILD in der prepare-Funktion eingetragen und dann beim Bauen des Pakets angewandt. Das machst du einmal und ist deutlich einfacher als wenn du jedes mal vor dem Kompilieren die Patche manuell anwenden musst. Wenn Patche nicht mehr benötigt werden, nimmst du sie einfach wieder raus, das ist alles ziemlich einfach weil nur mit Kopien des Quellcodes gearbeitet wird. Wenn man das Konzept einmal verinnerlicht hat ist es einfach genial und man möchte nichts anderes mehr.

Die aktuellen Snapshots des FLTK baue ich mir hier übrigens vollautomatisch und über einen systemd.timer gesteuert nach Veröffentlichung (meistens freitags) neu, ohne dass ich dafür auch nur einen Finger krumm machen muss.

…und es geht noch weiter: für die selbst gebauten Pakete erstellst du dir ein custom repo, das du als Installationsquelle in die pacman-Konfiguration aufnimmst, dadurch werden dann bei einem nächsten Gesamtsystemupdate auch deine aktualisieten Pakete installiert. Dadurch dass die Dateien dem Paketmanagement bekannt sind, kannst du sie auch ganz normal in das System installieren und brauchst nicht mit lokalen Verzeichnissen zu hantieren. Das hat alles wirklich nur Vorteile gegenüber anderen Verfahrensweisen.

Bbrikler · 12. Jan

eigentlich geht das alles sehr einfach:
1) pacman -S base-devel
2) PKGBUILD organisieren
2.1) wenns sein muß, änderungen am PKGBUILD machen
2.2) wenn was im PKGBUILDgeändert wurde updpkgsums laufen lassen
3) makepkg -rsi, den rest machen lassen

übrigens: makepkg -h

Dakuan · 12. Jan

Danke für die Tipps. Das wird aber wohl etwas dauern, bis ich das verinnerlicht habe. Das ist völlig anders, als ich das bisher kannte.

Bbrikler · 14. Jan

Dakuan vielleicht noch interessant: https://wiki.archlinux.org/title/Makepkg

Dakuan · 14. Jan

Danke für die Info. Aber momentan fehlt mir noch das Hintergrundwissen um das wirklich umsetzen zu können. Und ich will ja auch noch nicht eigene Programme systemweit installieren.

Testweise habe ich mal eines meiner aktuellen Projekte compiliert. Leider stürzt das immer wieder mal ab, bevorzugt wenn eine .BMP Datei geladen werden soll. Der Absturz passiert, laut core-dump, in der Klasse Fl_Shared_Image::compare().

Bevor ich da jemanden auf die Füße trete, würde ich gerne sicher stellen, dass ich nicht für den Fehler verantwortlich bin. Aber leider gibt es bei ArchLinux Nemiver oder ddd nicht und gdb direkt traue ich mir nicht zu. Wahrscheinlich bin ich für ArchLinux einfach zu blöd.

MMartin-MS · 14. Jan

Dakuan Leider stürzt das immer wieder mal ab, bevorzugt wenn eine .BMP Datei geladen werden soll.

Was stürzt ab, das kompilierte Binary oder das Bauen des Pakets?

Dakuan Aber leider gibt es bei ArchLinux Nemiver oder ddd nicht

Doch, sowohl als auch, beides im AUR:
https://aur.archlinux.org/packages/nemiver
https://aur.archlinux.org/packages/ddd

Nur nicht als fertiges Binärpaket, sondern du musst es aus den Quellen selber bauen.

Dakuan · 14. Jan

Es stürzt das kompilierte Binary ab. Ich kann prinzipiell auch damit arbeiten, bis eine .BMP Datei beteiligt ist. Der Absturz passiert auch nicht immer, also sagen wir mal in 50% der Fälle, wobei gemeinerweise die Vorgeschichte auch eine Rolle spielt.
Zusätzlich hatte ich zweimal einen Absturz bei einer .JPG Datei (bad alloc), wobei aus dem Coredump hervorgeht, dass die Bilddaten eine gigantische Größe haben müssten, was tatsächlich nicht der Fall ist. Die Daten werden aber, laut Coredump über mehrere Funktionen weiter gereicht. Das bedeutet die Ursache kann ganz woanders liegen kann.

Wenn ich blauäugig wäre, würde ich den Fehler FLTK zuschieben, aber meine Erfahrung sagt mir, das es auch an einer nicht beachteten und/oder geänderter Datenstruktur liegen könnte.

Core was generated by `./imgcom'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000728f6388ebeb in ?? () from /usr/lib/libc.so.6
(gdb) bt
#0  0x0000728f6388ebeb in ?? () from /usr/lib/libc.so.6
#1  0x0000651d2788ee18 in Fl_Shared_Image::compare(Fl_Shared_Image**, Fl_Shared_Image**) ()
#2  0x0000728f637615d2 in ?? () from /usr/lib/libc.so.6
#3  0x0000728f637619ed in qsort_r () from /usr/lib/libc.so.6
#4  0x0000651d2788f51e in Fl_Shared_Image::get(char const*, int, int) ()
#5  0x0000651d2785c6d4 in ImageBox_ld::load_image (this=0x651d4fc59dd0, 
    n=0x651d4fc594d0 "imgtest01.bmp") at ImageBox_ld.cpp:153

Das betreffende Programm ist bei mir seit 2019 eigentlich im Dauereinsatz (Ubuntu) mit gelegentlichen Erweiterungen.

Ich werde morgen mal sehen, ob ich nemiver zum laufen kriege. Mit ddd hatte ich früher oft gearbeitet, bis die Ubuntu-Version praktisch unbrauchbar wurde. Hat sich öfter mal aufgehängt oder sich seine eigen config zerschossen (was natürlich auch an fehlerhafter Anpassung von Seiten Ubuntus liegen könnte (kann ich aber nicht nachprüfen)). Daher bevorzuge ich Nemiver, auch wenn ich da den Umgang mit mit Coredumps nicht optimal finde.

MMartin-MS · 14. Jan

Ich habe dir mal das Installationspaket für nemiver gebaut und in die Cloud geladen: https://c.gmx.net/@327748706747023899/_qFApYeLSQWBALZnAVZsOg

Herunterladen und anschließend mit pacman -U nemiver-0.9.6-11-x86_64.pkg.tar.zst installieren.

Bbrikler · 15. Jan

Dakuan mein link ist mehr als hinweis auf die /etc/makepkg.conf gedacht, mit den MAKEFLAGS und BUILDDIR kannst du dir einiges an bauzeit sparen

Dakuan · 15. Jan

Das ist mir jetzt peinlich, aber ich bekomme Nemiver nicht richtig zum laufen.
Ich kann das Programm starten und auch meine Quelltexte laden. Aber alle Menüpunkte und Werkzeuge, die nicht Nemiver selbst betreffen sind deaktiviert (grau). Und in die Einstellungen sehen in etwa so aus wie bei Debian.

Was mir jedoch aufgefallen ist, ist dass der erste Breakpoint nicht auf "main()" steht:

int
main( int argc, char**argv ) {
    Fl_RGB_Image * icon;
    int err;
    int c;
=>  Fl::get_system_colors();
    Fl::scheme("gtk+");
    fl_register_images();
    Fl::background2( 255, 255, 255 );
    MainWindow * mwin = new MainWindow( mw_wid, mw_hig, "imgcom" );
    icon = new Fl_RGB_Image( &win_icn );

sondern 4 Zeilen tiefer. Das geht auch nicht weg, wenn ich alles neu compiliere.

T.M. · 16. Jan

Dakuan Was mir jedoch aufgefallen ist, ist dass der erste Breakpoint nicht auf "main()" steht:
int
main( int argc, char**argv ) {
Fl_RGB_Image * icon;
int err;
int c;
=> Fl::get_system_colors();
Fl::scheme("gtk+");
fl_register_images();
Fl::background2( 255, 255, 255 );
MainWindow * mwin = new MainWindow( mw_wid, mw_hig, "imgcom" );
icon = new Fl_RGB_Image( &win_icn );
sondern 4 Zeilen tiefer. Das geht auch nicht weg, wenn ich alles neu compiliere.D

Das ist ja auch kein Wunder. FI::get_system_colors(); ist die erste Zeile mit relevantem Code in dieser main-Funktion, Würdest Du Deine Variablen (icon, err und c) initialisieren, würde die Ausführung dort starten. Das Anlegen uninitialisierter Variablen auf dem Stack macht praktisch keinen Code, jedenfalls keinen, den ein Debugger im Quellcode durchläuft. Wenn Du das auf Maschinencode-Ebene debuggen willst, musst Du den Debugger entsprechend starten.

MMartin-MS · 16. Jan

Dakuan Das ist mir jetzt peinlich, aber ich bekomme Nemiver nicht richtig zum laufen.
Ich kann das Programm starten und auch meine Quelltexte laden. Aber alle Menüpunkte und Werkzeuge, die nicht Nemiver selbst betreffen sind deaktiviert (grau).

Hattest du es mit dem von mir erstellten Installationspakets versucht?

Dazu muss ich sagen, dass sich das Projekt nicht mehr in einer aktuellen Systemumgebung kompilieren ließ, weil es ein gtksourceviewmm in der Version 3.0 erwartet, das aktuelle Paket im offiziellen Repo aber schon auf Version 4.0 steht (obwohl es als 1:3.91.1 versioniert ist). Ich hatte deshalb im config die Verweise auf die Version 4.0 geändert, damit ließ sich das Paket auch bauen. Es kam zwar zu keinen formalen Fehlern aber es könnte trotzdem sein, dass die Version 4.0 inkompatibel mit der Version 3.0 ist und deswegen einige Menüpunkte und Werkzeuge nicht mehr funktionieren.

Ich habe dir ein Build 12 hochgeladen, das ich mit der Version 1:3.18.0 von gtksourceviewmm gebaut habe; vielleicht läuft es damit besser, es war das letzte offizielle Paket für die Versionsreihe 3.0: https://c.gmx.net/@327748706747023899/vwStl3NyTXeHcp8DKvPRoQ

Die Abhängigkeit habe ich direkt auf diese Version gesetzt, so dass du sie zusätzlich manuell installieren musst, das Installationspaket findest du im Arch-Archiv: https://archive.archlinux.org/packages/g/gtksourceviewmm/gtksourceviewmm-1%3A3.18.0-7-x86_64.pkg.tar.zst

Die Abhängigkeiten auf gdb und gsettings-desktop-schemas habe ich jetzt optional gesetzt, da sie für das Programm selber nicht benötigt werden, die müsstest du also noch installieren, falls sie noch nicht installiert sind.

Gibt es denn keinen aktuellen Debugger für Gnome-Projekte? Was verwenden denn die Gnome-Entwickler? Die letzte Änderungen an nemiver waren 2015, das scheint also nicht mehr weiter entwickelt zu werden, und das AUR-Projekt hat zur Zeit den Status "orphan", also auch keinen Betreuer mehr, der sich um die Probleme kümmern könnte. An den Quellen wurden in der Vergangenheit auch schon zwei Patche vorgenommen, um Kompilierfehler abzufangen, aber irgendwann wird Schluss sein, wenn sich darum keiner mehr kümmert. In sofern würde ich nach etwas aktuellem und zukunftssicheren Ausschau halten, denn auf ewig wird man nemiver nicht mehr lauffähig halten können.

[EDIT]
Ich war mal so frei, auch das Paket gtksourceviewmm aus den Quellen der Version 3.18 neu als gtksourceviewmm-30 zu bauen und einen Build 13 des nemiver mit einer Abhängigkeit auf dieses Paket.

Das hat den Vorteil, dass beide Versionen von gtksourceviewmm konfliktfrei installiert werden können, dass gtksourceviewmm-30 in einer aktuellen Umgebung gebaut und damit besser in die Umgebung passen sollte, und nemiver ebenfalls auf einem aktuellen Build von gtksourceviewmm aufsetzt, was vielleicht weitere Inkompatibilitäten beseitigen könnte.

Dakuan · 16. Jan

@ T.M.
Ich hatte das nur vorsichtshalber erwähnt, weil in der alten Ubuntu-Version der Breakpoint direkt auf main() steht.

@ Martin-MS
Leider hat sich auch mit der neuen (13) Version nichts geändert. Ich denke dass ich mich jetzt doch direkt mit gdb befassen muss. Immerhin habe ich durch die Core-Dumps eine leichte Ahnung wo ich suchen muss. (Wenn als Bildbreite eine negative 9-stellige Zahl übergeben wird, ist das schon verdächtig.)

Mir war nicht bekannt, dass nemiver nicht mehr weiter entwickelt wird. Meine alte Ubuntu-Version ist übrigens auch eine 0.9.6 Version. Da denke ich, dass nemiver keine weitere Mühe wert ist.

Martin-MS Was verwenden denn die Gnome-Entwickler?

Keine Ahnung. Die neue Version gefällt mir nicht, deswegen verwende Mate und Xfce. Ich hatte vor einigen Tagen zwar ausgiebig nach Debuggern gesucht, allerdings auch immer mit "archlinux" im Suchstring. Das Ergebnis war enttäuschend.

MMartin-MS · 16. Jan

Dakuan Leider hat sich auch mit der neuen (13) Version nichts geändert.

Schade… ich habe mir auch noch mal die Build-Skripts bei Ubuntu angesehen, aber da kann ich außer zwei Patche von 2018, die im AUR auch schon eingearbeitet waren, keine Unterschiede sehen.

Wie kann ich das denn überhaupt mal testen? Der Aufruf alleine reicht ja scheinbar nicht… auf welche Menüpunkte und Werkzeuge, die nicht Nemiver selbst betreffen muss ich achten? Ich habe für dich auch noch mal den ddd gebaut, und zwar mit Debug-Informationen, das kann ich in nemiver öffnen und ich sehe auch alle Menüpunkte aktiv. Ich habe bloß keine Ahnung, wie ich den bedienen muss, weil ich damit bisher nie zu tun hatte.

Du kannst ja mal beide ddd-Pakete installieren und dann das Binary mit nemiver öffnen, ich sehe dann den Quellcode, Breakpoints, usw., und auch keine inaktiven Menüpunkte, zumindest nicht so lange das Debugging ausgeführt wird.

Vielleicht hast du mit dem ddd etwas mehr Glück als bei Ubuntu.

Dakuan · 16. Jan

Martin-MS Wie kann ich das denn überhaupt mal testen? Der Aufruf alleine reicht ja scheinbar nicht…

Dazu wollte ich gerade ein Bild hochladen, welches ich auf erträgliche Größe zuschneiden wollte. Aber die Installation von Gimp ist gerade hängen geblieben:
lapack-3.12.0-5-x86_64.pkg.tar.zst konnte nicht heruntergeladen werden
Die Version von ddd scheint aber zu laufen. Danke dafür!
Da muss ich mich allerdings auch erst dran gewöhnen. Ich erinnere mich dunkel, das es für die Einstellungen im Ubuntu-Wiki vor etlichen Jahren dazu sinnvolle Tipps gab, aber die wurden wohl weg rationalisiert.

Martin-MS Ich habe bloß keine Ahnung, wie ich den bedienen muss, weil ich damit bisher nie zu tun hatte.

Wichtig ist das kleine Panel (sonst wird man verrückt). Breakpoint setzen geht mit Doppelklick auf die Zeilennummer. Ich rufe den immer aus der Konsole auf mit dem Programmnamen als Argument.
Ich hatte ddd zuletzt nur noch verwendet um ein fehlerhaftes Programm zu starten. Wenn das dann abgestürzt ist, konnte ich mir direkt den Backtrace ansehen (Status/Backtrace...). Das fand ich immer sehr hilfreich, zumal Ubuntu es einem neuerdings schwer macht, überhaupt einen Core-Dump auszuwerten oder zu erzeugen.