I tried
version 63 of this GTK+/X11 port on my computer. My processor is
PowerPC and my operating system is
OpenBSD 4.4-current. Here is my experience.
First, the configure script has some trouble finding dependencies. OpenBSD puts X11R7 in
/usr/X11R6 and packages in
/usr/local, and the compiler needs -I and -L flags to look there. Also
png.h is at a strange place. The config scripts know about this:
Code: Select all
$ libpng-config --cflags
-I/usr/local/include/libpng
$ pkg-config x11 --cflags
-I/usr/X11R6/include
$ sdl-config --libs
-L/usr/local/lib -lSDL -pthread -L/usr/X11R6/lib -R/usr/X11R6/lib
But the configure script does not use all these config scripts, so I had to use an
especially long configure line:
Code: Select all
./configure --prefix=$HOME/prefix --with-debug CPPFLAGS="`libpng-config --cflags` `pkg-config x11 --cflags`" LDFLAGS="-L/usr/local/lib -L/usr/X11R6/lib -pthread"
I added --with-debug later. I purposely did not give --with-opengl, because I do not have OpenGL acceleration.
With configure done, I used
make and
make install as normal. Then I started the emulator, but the emulator
crashed and dumped core! The first backtrace from gdb showed that emulator called
glade_xml_new_from_buffer which called
g_free which called libc
free which aborted on a "bogus pointer". I decided to try to fix this problem. I rebuilt snes9x-gtk using
--with-debug for a better backtrace. However, the crash seemed to be in libglade, so I wondered if my libglade would be broken. I ran a program called
galculator to verify that libglade works. I still wanted debugging info in libglade, so I deinstalled libglade, hacked the OpenBSD ports tree to build libglade with
-g, and installed a new copy of
/usr/local/lib/libglade-2.0.so.1.0. Finally I discovered the problem.
I ordered gdb to break at
glade_xml_new_from_buffer, and saw that
buffer contained a string of XML but
size was zero. When I told gdb to
print size=strlen(buffer) and
continue, snes9x-gtk temporarily worked! So I looked back through the source code of snes9x-gtk to find where the size was zero. I found this code in
gtk_glade.cpp:
Code: Select all
int snes9x_glade_size = 0;
char snes9x_glade [] =
{
60, 63, 120, 109, 108, 32, 118, 101, 114, 115, 105, 111, 110, 61,
...
This was the source of the size of zero. Then I guessed that some
reswrap-like program generated this file, so I searched Makefile, and found that
sourcify makes this. So the next step was to look in
sourcify.c, for a bug that sets the size to zero instead of the actual size. I found this code:
Code: Select all
stat (argv[1], &file_info);
...
fprintf (outfile, "int %s_size = %d;\n\n", argv[3], file_info.st_size);
I did
man 2 stat to check that
file_info.st_size is the size of the file. There I found the problem:
file_info.st_size has type
off_t, but
%d wants type
int. There is no type conversion because
fprintf takes variable arguments.
OpenBSD supports large files, so
off_t is 64 bits, but
int is only 32 bits. My PowerPC is big-endian, so the big end (zero) comes before the little end (the actual size), and that was the zero that crashed snes9x-gtk. So I changed line 31 of src/sourcify.c to use a cast:
Code: Select all
fprintf (outfile, "int %s_size = %d;\n\n", argv[3], (int)file_info.st_size);
fprintf (outfile, "int %s_size = %d;\n\n", argv[3],
(int)file_info.st_size);
I did
make and
make install again, and the bug died.
Code: Select all
int snes9x_glade_size = 404935;
char snes9x_glade [] =
{
60, 63, 120, 109, 108, 32, 118, 101, 114, 115, 105, 111, 110, 61,
...
I started snes9x-gtk and it did not crash. After I set a bunch of preferences, I had a good game of Super Mario World. With a long enough configure line and this small bug fix, snes9x-gtk is ready to run above OpenBSD.
Please fix this bug in the next version. Put an
(int) cast like I did above (which should work if the size fits an int) or otherwise match the types. Advance thank you.