Justin,
Sorry for getting back to you so late. Aside from the typical excuses, I also needed to learn a bit more about the commands you asked me to try out for this one, and how to reverse them if necessary.
In my case, I moved the current working directory to the Valgrind folder before creating the symbolic link (to cut down on typing in the terminal). I then entered the following:
*****@***** /usr/lib64/valgrind $ sudo ln -sv ./memcheck-amd64-linux ./memcheck-x86-linux
'./memcheck-x86-linux' -> './memcheck-amd64-linux'
...The -f flag was unnecessary here as no previous symbolic link was in conflict with the one being created, if my green understanding of the ln command is correct. Regardless, the symbolic link was created all-the-same.
Upon running Valgrind with the program of interest, here was the entry and output of the operation:
*****@***** ~/Desktop/Space Combat 140 $ valgrind -v ./"Space Combat 140"
valgrind: wrong ELF executable class (eg. 32-bit instead of 64-bit)
valgrind: ./Space Combat 140: cannot execute binary file
...I think this is conclusive with regards to whether the Solus Valgrind package is complete or not. It's not that it's wrong, per-se, but I am convinced it lacks the files to tackle some of the older 32-bit applications. From the viewpoint of a progressive 64-bit operating system, this may not be a problem... unless you are working with an older application.
Regarding my... project: another commentator suggested using strace to try and figure out the problem, and this has been delivering a few results so far. For instance, I assume that when you tried the program, you had the mesalib32-bit package installed already. I did not, but enough clues came up from strace to get the program to the point that the blue start-up GUI for the application appears with a dialogue box. Clicking the box of course causes a segfault, but there you go.
Anyway, the above is OT, but yes, I am confident in stating that Solus' Valgrind cannot evaluate 32-bit applications due to being an incomplete package.
