PureBoard

Hallo,

Kann das hier mal jemand unter MacOS -Intel 64bit testen.

Old-Style-GUI

Läuft das kleine Mini-Test-Program: Ja oder Nein?

Hier läuft es nicht ...

Sind die DyLib auch als Intel kompiliert oder als M1

Du must zwei version von den DyLib erstellen:
- Intel
- M1

Hallo mk-soft

Die Lib ist mit dem g++ (nicht clang) unter MacOs 11.6 mit Intel-Prozessor kompiliert.

Ich denke es werden die zusätzlichen C++ Bibliotheken nicht gefunden.
(Kompiliert mit -rpath . Angabe)

Versuche mal:
brew install fltk

Danach sollte es eigentlich funktionieren.

Ja und nun?
Geht es oder geht es nicht?

Ich bekomme die Lib nicht statisch gelinkt. (libcrt0 - Fehler, etc.)
Und eine -rpath Angaben aller zusätzlichen Libs bringt nichts.
Auch das setzen von "LD_LIBRARY_PATH" bringt nichts.
Wenn die Fltk-Lib ordentlich mit brew oder MacPorts installiert wurde (im trusted usr/local/lib/.. -Verzeichnis) sollte es eigentlich gehen, oder?
Bei korrekter Installation kann man auch beim Kompilieren die -l.. -Angaben weglassen und mit fltk-config übersetzen.

Der MacOs-Fehler-/Absturzbericht sagt eigentlich auch immer wo PureBasic gerne die eingebunden oder von anderen Quellen abhängige Lib's sucht.
Zum Beispiel hier:
/usr/local/opt/fltk/lib/

Alle benötigten (auch statische) Abhängigkeiten (ohne die C++ Runtime mitzuzählen) sind:
libfltk.1.3.dylib
libfltk_forms.1.3.dylib
libfltk_images.1.3.dylib
libfltk_gl.1.3.dylib
libjpeg.9.dylib
libpng16.16.dylib

Hat irgendjemand eine Ahnung (vlt. mk-soft) ob man das Management mit den Library-Abhängigkeiten irgendwie über das Tool:
"install_name_tool -change" hinbekommt?

Abfragen kann man die Abhängigkeiten im übrigen mit "otool -L" .

Ich habe mal alle Pfade geändert und es kommt jetzt absolut keine Fehlermeldung (auch im Terminal nicht) mehr, aber die App startet nicht.
Wenn die lib-Dateien aber in usr/local/lib/ sind startet die App ganz normal.

Hier nochmal ein Test:
Old-Style-GUI-Test4.1

Ich bin nicht zum testen gekommen,

aber versuch mal die lib's mit in die APP zu laden

Link: PB-IDE Tool MyAppData
Link: PathHelper Include

./MyAppData/Library/

Ausserdem ist bei dir im Code ein "/" slash in path zur Library zu viel ...

Update! Es sollte jetzt "Standalone" gehen.

Und läuft es?

Ich versuche einen sehr komischen Bug unter Linux zu finden.

Unter MacOS kann man das Fenster einfach wie gewohnt schließen und der Event-Loop ( FL_Run() ) beendet sich und das ganze Programm wird beendet (incl. Debugger).

Dieses Verhalten ist somit in Ordnung.

Unter Linux (Manjaro - Xfce 4.16) bleibt das Fenster aber nach schließen des Event-Loop (FL_Run() ) immer noch sichtbar.
Erst wenn man FL_Flush() danach aufruft wird das sichtbare Fenster unsichtbar (geschlossen?).
Das Programm hat dann auch das Ende erreicht und es wird "Debug Ende" ausgegeben, aber der Debugger ist immer noch aktiv und das Programm läuft ohne aktiven Eventloop und ohne sichtbares Fenster im Hintergrund einfach weiter.

Auf der Konsole gibt es nur eine Fehlermeldung:

X_ChangeProperty: BadValue (integer parameter out of range for operation) 0x0

Diese Meldung wird von FL_WindowShow(win) ausgelöst und lässt sich durch Verwendung von FL_WidgetShow(win) beheben, aber das fehlerhafte Debuggerverhalten bleibt weiterhin bestehen.

Dieser Eventloop fuktioniert unter Linux (Manjaro - Xfce 4.16), weil FL_Run() unter Linux fehlerhaft ist.
...Aber der Debugger bleibt danach trotzdem aktiv und das Programm ist still am Leben.

Bei Verwendung von "exit_(0)" als Befehl dauert es einen kurzen Moment und dann kommt:
"Das mit dem Debugger getestete Executable endete unerwartet."

Auf den PureBasic-Befehl "End" am Ende wird aber zum Beispiel gar nicht reagiert.

Der Destructor des Fenster wird aber korrekt aufgerufen und der Eventloop wird auch korrekt mit 0 beendet, aber das Programm bleibt innerhalb der IDE sowohl mit (als auch ohne) Debugger weiter hin aktiv und wird nicht korrekt beendet

Wenn man das Programm aber als "Console"-Programm als fertige Executable kompiliert und ohne Debugger außerhalb der IDE startet wird es korrekt im Taskmanager beenden.

???

-> Dieses seltsame Verhalten lässt sich auf FL_SetScheme() zurückführen.
-> Wenn man diesen Befehl nicht einsetzt beendet sich das Programm ganz normal.

Das Ganze wird weiter untersucht.
-> Bin am basteln einer "Fltk-Style.pbi"

...
Insgesamt ist vieles bisher ein Gebastel von sehr vielen Problemumgehungen (Workarounds).
Aktuell suche ich eine Alternative zu: "FL_DrawReadImage", weil diese Funktion unter MacOs nicht funktioniert.

Anbei:
Ein weiteres großes Problem stellt auch noch die Implementierung von Objekten (Interface(Class)-Integration) dar.
(Steht aber auf der "ToDo-Liste".)