Two comments on that:

1. The executable is not the only thing that needs to be checked. I have not checked every library in its chain of dependencies to make sure that not a single one of them is linked against libpng 12. And no, I won't do that.

2. If this is indeed the issue, then I would find it very strange that VBAM seems to be the only program affected.

Also, anyone who solves this before I do gets offered ownership of the SlackBuild.

Ok, I was completely off on that guess.

On non-multilib Slackware64-14.0 I've just compiled vbam using the slackbuild. The program seems to run fine and doesn't crash with libpng incompatibility errors. So perhaps it's a multilib build problem? I don't have a multilib system so I can't look into it myself. ldd points to the 64 bit libpng on my system.

Interesting that it works for you. I just tested it on a 32-bit VM and had the same problem yilez (the OP) did.

The 32-bit version works here. I haven't done anything special either. Dependencies taken care of first as usual, then vbam installed without the ffmpeg option.

Only other thing I can think of and a complete stab in the dark is that I'm using fluxbox which I don't think uses gtk themes.

Okay, the icons still don't work, but let me know if this still crashes. It's a SlackBuild for r1199 that statically links libpng and zlib.

Source:
http://www.duganchen.ca/files/vbam-r1199-src.tar.bz2

SlackBuild:
http://pastebin.com/EFczu0P0

Don't you need SDL for OpenGL rendering?

For me... it crashes every so often still without so much as a warning. I've tried to grep the logfile, but nothing except the program simply terminated execution. Turned on debugging build and nothing also. I'm getting no icons also.

Kinda wondering what the heck they are doing using outdated static libs within the project rather than using the dynamic or static system libs with simple compatibility workaround internally.

Dugan you should look at the source code as to how much of a mess it is.

1 members found this post helpful.

No you don't. Turning on SDL just gives you a GUI-less command-line executable.

The GUI builds use SFML, which is a competitor to SDL.

Ah... hmmm... then again SDL does have a GUI project, but not certain how it's development has been going. I think there was one for SDL_GTK or something.

I think this proves your point about what a mess the source code is. :P

In addition to Higan, other options you might try are: Mednafen, or the Windows version of VBAM in Wine.

I've had other slackbuilds complain on multilib due to trying to build against 32bit libs instead of 64 bit libs. Had to:

mv /usr/lib /usr/lib_
run slackbuild
mv /usr/lib_ /usr/lib

to get one to build.

EDIT: This doesn't work, by the way

Something is really screwy here.

Only the old version was getting mixed up with the zlib problem. As for the newer version, it looks like it is trying to load images that are incompatible with this version of libpng. Perhaps gvbam isn't incompatibility very well and is crapping out instead of resorting to something else.

I honestly don't know. I do know that rebuilding the icon theme set did nothing.

Thinking about it again, it might be the recent file menu. It does also happen to be the last error before crashing (I get alsa underrun occasionally but it's not fatal). From the behaviour you described it ran the first time but crashed after loading a file. It then crashed on startup on subsequent runs. The difference being that the recent menu now has an entry to it and trying to load the associated menu is causing it to crash.

Indeed. The recent menu is the only thing that will have changed. In fact, removing the entry from .local/share/recently-used.xbel allows me to load up the GUI again.

I am testing a few things at the moment. I think I know what the problem is, but I need to test first.