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.

      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.

          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

          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.

          • brikler hat auf diesen Beitrag geantwortet.

            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.

              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.

                  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.

                  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

                    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.

                        • Beitrag Nr. 16

                        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.

                          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 hat auf diesen Beitrag geantwortet.

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

                              • Martin-MS hat auf diesen Beitrag geantwortet.

                                  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 hat auf diesen Beitrag geantwortet.

                                      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.

                                      • Martin-MS hat auf diesen Beitrag geantwortet.

                                            Dakuan lapack-3.12.0-5-x86_64.pkg.tar.zst konnte nicht heruntergeladen werden

                                            …weil es eine neuere Version gibt und deine pacman-Datenbank noch auf einem alten Stand ist.

                                            Arch unterstützt keine Teilaktualisierungen, deswegen mit pacman -Syu zunächst das gesamte System aktualisieren und danach erst gimp installieren.

                                            Ich habe dir mal zwei Screenshots hochgeladen, so wie nemiver aussieht wenn ddd zum debugging geöffnet ist, einmal wenn es läuft (mit Breakpoint) und einmal die Menüansicht.

                                            • Dakuan hat auf diesen Beitrag geantwortet.

                                                Martin-MS …weil es eine neuere Version gibt

                                                Ok, es gibt noch eine Menge zu lernen. Jetzt funktioniert gimp (erstmal).
                                                Deine Screenshots sehen eigentlich so aus, wie ich es erwarten würde. Da würde ich erst mal vermuten, dass es sich bei mir um ein Konfigurationsproblem handelt oder dass etwas fehlt. Außerdem stelle ich gerade fest, dass man hier Bilder nicht so einfach hochladen kann. Dafür müsste ich meinen Server, den ich eigentlich schon abmelden wollte, umkonfigurieren.

                                                  Nochmal zu den Screenshots. Bei mir ist z.B. unter dem Menüpunkt Diagnose alles, außer Anhalten deaktiviert. In der Werkzeugleiste ist es genau so. Um sicher zu gehen habe ich mein Programm mal über das Menü Datei/Ausführen und dem dann erscheinenden Auswahlfenster ausgewählt. Nach drücken von Ausführen kommt dann
                                                  Assertation failed: editor
                                                  Was immer das bedeuten soll. Wenn ich das Meldungsfenster dann weg klicke, kommt ein Absturz:

                                                  ...
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Core was generated by `nemiver ./imgcom'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000741a866c7ca3 in std::_Rb_tree_rebalance_for_erase (
    __z=0x624bb36b6a80, __header=...)
    at /usr/src/debug/gcc/gcc/libstdc++-v3/src/c++98/tree.cc:305

warning: 305	/usr/src/debug/gcc/gcc/libstdc++-v3/src/c++98/tree.cc: Datei oder Verzeichnis nicht gefunden
[Current thread is 1 (Thread 0x741a82beb9c0 (LWP 7446))]
(gdb) bt
#0  0x0000741a866c7ca3 in std::_Rb_tree_rebalance_for_erase (
    __z=0x624bb36b6a80, __header=...)
    at /usr/src/debug/gcc/gcc/libstdc++-v3/src/c++98/tree.cc:305
#1  0x0000741a8026187a in ?? () from /usr/lib/nemiver/modules/libgdbmod.so
#2  0x0000741a80261d2c in ?? () from /usr/lib/nemiver/modules/libgdbmod.so
#3  0x0000741a8024fbae in nemiver::OutputHandlerList::submit_command_and_output(nemiver::CommandAndOutput&) () from /usr/lib/nemiver/modules/libgdbmod.so
#4  0x0000741a802756a1 in nemiver::GDBEngine::on_debugger_stdout_signal(nemiver::CommandAndOutput&) () from /usr/lib/nemiver/modules/libgdbmod.so
#5  0x0000741a80291e5e in ?? () from /usr/lib/nemiver/modules/libgdbmod.so
#6  0x0000741a80258dc5 in nemiver::GDBEngine::Priv::on_gdb_stdout_signal(nemiver::common::UString const&) () from /usr/lib/nemiver/modules/libgdbmod.so
#7  0x0000741a80291e5e in ?? () from /usr/lib/nemiver/modules/libgdbmod.so
#8  0x0000741a8025fec8 in nemiver::GDBEngine::Priv::on_gdb_stdout_has_data_signal(Glib::IOCondition) () from /usr/lib/nemiver/modules/libgdbmod.so
#9  0x0000741a87749c03 in ?? () from /usr/lib/libglibmm-2.4.so.1
#10 0x0000741a8690d559 in ?? () from /usr/lib/libglib-2.0.so.0
#11 0x0000741a86970257 in ?? () from /usr/lib/libglib-2.0.so.0
#12 0x0000741a8690e287 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#13 0x0000741a86be4ebf in gtk_main () from /usr/lib/libgtk-3.so.0
#14 0x0000624b951d7273 in main ()
(gdb)

                                                  Ich denke nemiver kann man vergessen. Und ich habe mich fast schon wieder an ddd gewöhnt. Zumindest funktioniert Deine Version.

                                                  Und ich werde wohl die nächste Zeit damit beschäftigt sein, meine Programme von FLTK 1.3.x auf 1.4.x umzustellen. Die haben die Klasse Fl_Image komplett umgekrempelt. Warnungen wegen des geänderten ABI's gibt es keine. Die haben einfach die alten Methoden mit geänderter Funktionalität ausgestattet (gleiche Signatur).

                                                  • Martin-MS hat auf diesen Beitrag geantwortet.

                                                    Dakuan Bei mir ist z.B. unter dem Menüpunkt Diagnose alles, außer Anhalten deaktiviert. In der Werkzeugleiste ist es genau so.

                                                    Solange eine Diagnose läuft, sind die anderen Menüpunkte inaktiv. Wenn du auf Anhalten drückst, wird die Diagnose deaktiviert und die anderen Menüpunkte sind wieder aktiv. Das Verhalten ist für mich bis hierher noch logisch, danach hört es bei mir aber mit der Logik auf.

                                                    Dakuan Um sicher zu gehen habe ich mein Programm mal über das Menü Datei/Ausführen und dem dann erscheinenden Auswahlfenster ausgewählt.

                                                    So habe ich es auch gemacht, allerdings mit dem ddd und dem Debug-Paket, da ich aktuell keinen Coredump einer Anwendung mit Debug-Informationen habe.

                                                    Wenn man das Binary aufruft, erscheint ein Haltepunkt an der ersten ausführbaren Anweisung in main und die Anhalten-Schalfläche ist aktiv, aber es passiert weiter nichts, vor allem wird die Anwendung offensichtlich nicht ausgeführt. Sooft ich auch die Diagnose anhalte und fortsetze, oder einen Neustart durchführen, es wird immer nur die Anhalten-Schaltfläche aktiv, sonst passiert nichts weiter.

                                                    Interessanter wird es (und dafür habe ich einige Zeit gebraucht…) wenn man die Diagnose ausschaltet und in dem dann wieder aktiven Diagnose-Menü auf Asm nachfolgen (Strg+I) oder Asm abarbeiten (Strg+N) drückt. Dann erscheint ein neuer Tab mit dem Assembler-Code, und einem gelben Programmzeiger. Wenn man dann wieder in das Quellcode-Fenster wechselt und auf Fortsetzen drückt, erscheint der gelbe Zeiger auch auf dem gesetzten Haltepunkt und ab da kann man sich schrittweise fortbewegen, sich die Variableninhalte anzeigen oder überwachen lassen, und vor allem startet jetzt auch die Anwendung selber.

                                                    Ob das alles so vom Autor gedacht ist kann ich mangels Erfahrung mit dem Teil nicht sagen, und fragen kann man ihn auch nicht mehr. Es läuft aus meiner Sicht jedenfalls reichlich holprig und gewöhnungsbedürftig, aber es scheint zu funktionieren. Die Arbeit damit stelle ich mir trotzdem nervig vor.

                                                    Dakuan arning: 305 /usr/src/debug/gcc/gcc/libstdc++-v3/src/c++98/tree.cc: Datei oder Verzeichnis nicht gefunden

                                                    Das sieht mir danach aus, als wenn das Debug-Paket für den gcc nicht installiert ist. Wahrscheinlich soll dort ein Funktionsaufruf verfolgt werden. Das Paket könntest du vom Mirror https://geo.mirror.pkgbuild.com/core-debug/os/x86_64 bekommen, ist aber recht groß, und wenn ddd es auch ohne kann dann würde ich dabei bleiben.

                                                    [Edit]
                                                    Ich habe noch einen interessanten Debugger gefunden, und zwar seer
                                                    Der benötigt zwar das Qt-Framework und zieht deswegen möglicherweise noch etwas an abhängigen Paketen nach, wird aber scheinbar noch aktiv entwickelt und wurde auch schon auf Qt6 portiert.
                                                    Ich habe ihn mal kurz getestet und er lief auf Anhieb, und war auch optisch etwas ansprechender als der ddd mit seiner Motif-Oberfläche.
                                                    Da er auch wieder nur im AUR angeboten wird und deswegen selber kompiliert werden muss, habe ich dir ein fertiges Installationspaket hochgeladen.