Old-Style-GUI-Lib-Test :)

MAC OSX spezifisches Forum
Beiträge, die plattformübergreifend sind, gehören ins 'Allgemein'-Forum.
ccode_new
Beiträge: 1169
Registriert: 27.11.2016 18:13
Wohnort: Erzgebirge

Old-Style-GUI-Lib-Test :)

Beitrag von ccode_new »

Hallo,

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

Old-Style-GUI

Läuft das kleine Mini-Test-Program: Ja oder Nein?
Betriebssysteme: Windows 11 (mit WSL (Linux)) / RaspberryPi OS - Bullseye / Mac OS 11 / Android 11
...
Benutzeravatar
mk-soft
Beiträge: 3446
Registriert: 24.11.2004 13:12
Wohnort: Germany

Re: Old-Style-GUI-Lib-Test :)

Beitrag von mk-soft »

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
Alles ist möglich, fragt sich nur wie...
Projekte ThreadToGUI / EventDesigner V3 / OOP-BaseClass-Modul / OPC-Helper DLL
PB v3.30 / v5.7x - OS Mac Mini OSX 10.xx / Window 10 Pro. (X64) /Window 7 Pro. (X64) / Window XP Pro. (X86) / Ubuntu 14.04
Downloads auf My Webspace
ccode_new
Beiträge: 1169
Registriert: 27.11.2016 18:13
Wohnort: Erzgebirge

Re: Old-Style-GUI-Lib-Test :)

Beitrag von ccode_new »

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.
Betriebssysteme: Windows 11 (mit WSL (Linux)) / RaspberryPi OS - Bullseye / Mac OS 11 / Android 11
...
ccode_new
Beiträge: 1169
Registriert: 27.11.2016 18:13
Wohnort: Erzgebirge

Re: Old-Style-GUI-Lib-Test :)

Beitrag von ccode_new »

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
Zuletzt geändert von ccode_new am 26.07.2022 18:00, insgesamt 1-mal geändert.
Betriebssysteme: Windows 11 (mit WSL (Linux)) / RaspberryPi OS - Bullseye / Mac OS 11 / Android 11
...
ccode_new
Beiträge: 1169
Registriert: 27.11.2016 18:13
Wohnort: Erzgebirge

Re: Old-Style-GUI-Lib-Test :)

Beitrag von ccode_new »

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-Test3.1
Zuletzt geändert von ccode_new am 31.07.2022 19:49, insgesamt 5-mal geändert.
Betriebssysteme: Windows 11 (mit WSL (Linux)) / RaspberryPi OS - Bullseye / Mac OS 11 / Android 11
...
Benutzeravatar
mk-soft
Beiträge: 3446
Registriert: 24.11.2004 13:12
Wohnort: Germany

Re: Old-Style-GUI-Lib-Test :)

Beitrag von mk-soft »

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

Code: Alles auswählen

;Fltk_Lib = OpenLibrary(#PB_Any, GetCurrentDirectory()+"/Library/libfltk-c-1.3.8-64_mac.dylib")
Fltk_Lib = OpenLibrary(#PB_Any, GetCurrentDirectory()+"Library/libfltk-c-1.3.8-64_mac.dylib")
Alles ist möglich, fragt sich nur wie...
Projekte ThreadToGUI / EventDesigner V3 / OOP-BaseClass-Modul / OPC-Helper DLL
PB v3.30 / v5.7x - OS Mac Mini OSX 10.xx / Window 10 Pro. (X64) /Window 7 Pro. (X64) / Window XP Pro. (X86) / Ubuntu 14.04
Downloads auf My Webspace
ccode_new
Beiträge: 1169
Registriert: 27.11.2016 18:13
Wohnort: Erzgebirge

Re: Old-Style-GUI-Lib-Test :)

Beitrag von ccode_new »

Update! Es sollte jetzt "Standalone" gehen.

Und läuft es?

:lurk:
Betriebssysteme: Windows 11 (mit WSL (Linux)) / RaspberryPi OS - Bullseye / Mac OS 11 / Android 11
...
ccode_new
Beiträge: 1169
Registriert: 27.11.2016 18:13
Wohnort: Erzgebirge

Re: Old-Style-GUI-Lib-Test :)

Beitrag von ccode_new »

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.

Code: Alles auswählen

While FL_Check()
  FL_Flush()
Wend
...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.
Betriebssysteme: Windows 11 (mit WSL (Linux)) / RaspberryPi OS - Bullseye / Mac OS 11 / Android 11
...
Antworten