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.

      Ich komme mit ddd erstmal zurecht. Mir ist allerdings auch klar, dass das keine dauerhafte Lösung sein kann, wenn das nicht aktiv weiter entwickelt wird. Wobei "aktiv weiter entwickelt" nicht unbedingt ein Qualitätsmerkmal sein muss (außer bei Debian vielleicht). Was ich damit sagen will ist: Ich hatte schon zu Windows-98 Zeiten ein Programm, welches ich erst zu [https://de.wikipedia.org/wiki/Coherent_(Betriebssystem)] und später zu Linux portiert hatte. Die Update/Erweiterungs - Intervalle lagen im Bereich von Jahren (was nicht typisch sein muss). Das Programm hat aber immer seine Aufgabe erfüllt.

      Ich habe noch einen interessanten Debugger gefunden, und zwar seer ...

      Da muss ich erst mal eine Weile drüber nachdenken. Um Qt hatte ich bisher immer einen großen Bogen gemacht. Nicht dass ich das schlecht finde, aber das entspricht nicht meiner Denkwelt. Ich war früher mit SUSE 8.x unterwegs und fand das auch Ok, aber in einer Umgebung mit MATE und FLTK muss ich über diese Alternative noch einmal nachdenken.

      Mir ist allerdings auch klar, dass Nemiver oder ddd, aus heutiger Sicht, keine dauerhafte Lösung sein können.

      Da er auch wieder nur im AUR angeboten wird und deswegen selber kompiliert werden muss, habe ich dir ein fertiges Installationspaket hochgeladen.

      Den muss ich mir dann Morgen wohl mal näher ansehen. Der aktuelle PC ist ja noch kein Produktivsystem, da kann man ja die zusätzlichen Abhängigkeiten mal riskieren.

      Ich bin jetzt endlich dazu gekommen seer auszuprobieren. Lief auf Anhieb! Es erfordert aber wohl etwas Einarbeitungszeit. Das ist etwa wie der Umstieg von Paint auf Gimp. Macht einen guten Eindruck.

      Das Ausprobieren von seer hat sich etwas verzögert, weil ich ersmal zwei meiner FLTK Programme an die neue Version (1.4.x) anpassen wollte. Es stellte sich heraus, dass meine Programme nicht komplett fehlerhaft waren, aber einige Aktionen, die ich bisher mit Bildern gemacht hatte, mit der Klasse Fl_Shared_Image nicht mehr erlaubt sind. Wenn ich meine Bilder selber lade und mich auf Fl_RGB_Image beschräke, funktioniert alles wie bisher.

      Jetzt kann ich anfangen, zu lernen, wie ich daraus ein funktionierendes Paket bauen kann.

      19 Tage später

      Ich muss mich noch einmal für die lauffähige Version von ddd bedanken. Ich habe mich schon wieder dran gewöhnt und es funktioniert besser als früher unter Ubuntu. Ich würde sogar dafür stimmen, es in die offizielle Paketliste aufzunehmen.
      seer funktioniert bei mir (unter Mate) nur eingeschränkt. Die interessanten Funktionen zur Anzeige der Datenstrukturen funktionieren nicht, oder ich bin dafür zu blöd für die richtigen Eingaben.
      Momentan kämpfe ich damit, wie Dateimanager z.B. bei einem Drag-and-Drop die einzufügende Datei benennen und wie ich das dann umsetzen kann, wenn mein Programm kein smb oder ftp spricht. Falls da dann die Environment Variable XDG_RUNTIME_DIR gesetzt ist, kann man dann einen Umweg gehen, wozu es dann aber einen Dolmetscher braucht.
      Um herauszufinden, wie man da vorgehen muss und das auch zu testen, war ddd eine gute Hilfe. Ein Beispiel wie von:
      smb://lager1/homes/manfred/data/Black%20Mountain%20Rag.mp4
      zu:
      /run/user/1000/gvfs/smb-share:server=lager1,share=homes/manfred/data/Black%20Mountain%20Rag.mp4
      zu konvertieren ist. Wobei der vordere Anteil von der jeweiligen User-ID abhängig ist.
      Ich sehe langsam Licht am Ende des Tunnels, und denke nicht , dass es eine Lokomotive ist :-)