| |
Slajerek
Registered: May 2015
Posts: 63 |
Release id #187948 : C64 65XE Debugger V0.64.58
I am using NFD library to open files in Linux. Please guide me how to fix this annoying bug.
https://sourceforge.net/p/c64-debugger/code/ci/master/tree/MTEn.. |
|
... 15 posts hidden. Click here to view all posts....
|
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote:
$ ./c64debugger-064582rc2-linux-x64
./c64debugger-064582rc2-linux-x64: error while loading shared libraries: libxcb-util.so.0: cannot open shared object file: No such file or directory
$ locate libxcb-util.so
/usr/lib64/libxcb-util.so
/usr/lib64/libxcb-util.so.1
/usr/lib64/libxcb-util.so.1.0.0
do you really need to import that specific version? :)
Just symlink and wait for a segfault! ;) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11391 |
NO! |
| |
Slajerek
Registered: May 2015
Posts: 63 |
I do not link anything specifically, this is the Makefile:
https://sourceforge.net/p/c64-debugger/code/ci/master/tree/MTEn..
Meaning that my old build machine Debian is outdated or what? I actually do not understand why this fails, anyway some so magic from Linux :) meaning that it should be easy to fix, I just need to scrap my faithful Debian into a new brand whatever distribution in which that compiles properly. Looks like old configuration for pkg-config... but why this fails on your machines I do not know. For me it is a pkg-config bug. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11391 |
static linking is always a gamble....to make it really work, you really have to statically link ALL libs, not just some =D
what repo/branch do i have to build? that will be easier =) |
| |
Slajerek
Registered: May 2015
Posts: 63 |
This is on Sourceforge here:
https://sourceforge.net/p/c64-debugger/code/ci/master/tree/
It should be just matter of cd MTEngine; make |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
I checked out the latest version from trunk, moved ~/.C64Debugger/settings.dat to settings.dat.bak (to avoid using the X11 dialogs), and now Ctrl+8 actually pops up a usable Gtk3 dialog.
Edit:
uname: Linux debian 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2 (2020-04-29) x86_64 GNU/Linux
/etc/debian_version: 10.4
gtk3: 3.24.5
glib: 2.58.3
|
| |
Compyx
Registered: Jan 2005
Posts: 631 |
While am at it, Gtk4 will deprecated/remove `result = gtk_dialog_run()` because that breaks the nature of a UI, a UI is event driven and thus async. I agree with the Gtk devs at this point.
So in the 'future', NFD (or perhaps your own custom code) will have to set up a temp GMainLoop, create a GtkDialog with an event handler for "response" and in that event handler call back to your code to signal a filename/path was accepted, or not.
The problem with this is that gtk_dialog_run() blocks, but:
GtkWidget *dialog = gtk_dialog_new(...);
gtk_widget_show(dialog);
will not.
So you need to make the dialog 'Modal'. Since you don't have a proper GtkWindow/Widget to use as a parent to set Modal for, you'd have to use some OS-dependent code to somehow grab an X11, Win32 or whatever window handle via GDK
and use that as the parent.
Another thing is unrolling the GMainLoop events and then destroying the temp GMainLoop, via the GtkDialog's "response" event handler. I have a feeling it'll not go well.
By Wodan, I love Gtk (or any other UI toolkit with its own threads and objects, looking at you Qt!) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11391 |
Works here too!
One weird thing... UPX crashes when packing the exe... which is weird and unexpected. However, i'd suggest making this a seperate build step, and copy the binary to be packed first - in that case UPX crashing wont really matter and still leave you with a working binary. (actually... just dont use upx, 11mb is nothing, depacking will be slower than just loading the binary) |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
I did this without upx. UPX is weird and just adds a lot of time to the build process. |
| |
Slajerek
Registered: May 2015
Posts: 63 |
I just kept UPX because it looks nice to see a small self-contained and portable binary, but more and more people are complaining so I guess I'll have to give it a go.
Regarding that experimental dev version, note it uses Zenity, not direct GTK. Thus, the dialog is spawned through a forked process that communicates over stdout, meaning that the original process does not have to have the GMainLoop. I hope that solves that open/file dialogs problem once for all :) Thanks for testing. |
| Previous - 1 | 2 | 3 - Next |
