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.
Dakuan vielleicht noch interessant: https://wiki.archlinux.org/title/Makepkg
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:153Das 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.
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.
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.
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.
@ 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.
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.
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.
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.
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).
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.