Mugen Mode doesn't work (Ubuntu Linux 14.04)

[Nobun]

Hi. I compiled paintown 3.6.1. with easy-compile-ubuntu on my UBUNTU 14.04 LTS
Paintown remained in my $HOME/programmi/paintown directory. I added no data in mugen (so... only default mugen screenpack and only kfm) but it was impossible to play.

At first step, rightly after kfm intro scene (before vs screen) this message occurred:

We are very sorry but an error has occured while trying to load MUGEN.
build/sdl/mugen/versus.cpp:189 Could not load versus screen because
build/sdl/util/file-system.cpp:581 Could not find
'/home/user/.paintown/mugen-cache/mugen-data-system.def

So I created a $HOME/.paintown/mugen-cache directory and I populated it with a bash script (copying original mugen/data into that directory as mugen-data-something or mugen-char-something and so on).

After this try, another problem occurred.
At this time I was able to see vs screen (kfm vs kfm) but, at the moment, a new error appears

We are very sorry but an error has occured while trying to load MUGEN.
build/sdl/mugen/parse-cache.cpp:164 data/mugen/data/ contains no bytes

And I am stuck. I don't know how to solve those problems :/

Thank a lot for your time

[Jon Rafkind]

Is your username literally 'user'? What does 'echo $HOME' produce? Mugen mode works for me on ubuntu 14.04. Something seems very strange about your setup.

[Nobun]

Obliouvsly, it is. It is the username I selected when I installed Ubuntu by myself removing completely preinstalled windows8 OEM (and disabling secure boot).

Here is the bash script I made to populate my mugen-cache with fake copies (runned when logged as "user", obliuovsly)

#! /bin/sh

# BASEPATH is where mugen cache must be stored
# MYSTIC_BASEPATH is a magic mugen cache... where all / are replaced by - (useful for sed)
# PAINTOWN is where paintown sources are stored (from where you builded paintown)
# MUGEN_SRC is the "mugen" sub-directory of PAINTOWN

BASEPATH=$HOME/.paintown/mugen-cache
PAINTOWN=$HOME/programmi/paintown
MUGEN_SRC=$PAINTOWN/data/mugen

MYSTIC_BASEPATH=$(echo $BASEPATH | sed "s,/,-,g")

if [ ! -d $BASEPATH ]; then
mkdir -p $BASEPATH
else
rm -r $BASEPATH
mkdir -p $BASEPATH
fi

for i in $( find $MUGEN_SRC -type f )
do
NEW_FNAME=$(echo $i | sed "s,$MUGEN_SRC,$MYSTIC_BASEPATH,g" | sed "s,/,-,g" | sed "s,$MYSTIC_BASEPATH-,$BASEPATH/mugen-,g")
cp $i $NEW_FNAME
done

echo " "
echo "paintown mugen cache updated"
echo " "

As you can see, my bash script doesn't use directly /home/user but uses, however, $HOME variable. And paintown, obliouvsly, is actually stored in /home/user/programmi/paintown (so paintown is really in $HOME/programmi/paintown... sources + paintown binary file).

After using this bash script (that actually populates /home/user/.paintown/mugen-cache as desired) I obtained the second error message.

NOTE: I have Ubuntu 14.04 64bit... don't know if 64bit arch could be a problem, but I add this information

[Nobun]

I can confirm that it was a bug of 3.6.1 version.
I tried 3.6.0 version and that one works.

IMPORTANT NOTE for Ubuntu 14.04 (64 bit) users:
In order to compile version 3.6.0 correctly you must change SConstruct manully adding a "-pthread" flag on line 1407, rightly before "-o $TARGET".
So the resulting line must be:

def gcc(env):
if useDistcc():
env['CC'] = 'distcc'
env['CXX'] = 'distcc g++'
if isOSX104():
env['LINKCOM'] = '$CXX $LINKFLAGS $SOURCES $_FRAMEWORKS -Wl,-all_load $_LIBDIRFLAGS $_LIBFLAGS $ARCHIVES -o $TARGET'
else:
env['LINKCOM'] = '$CXX $LINKFLAGS $SOURCES -Wl,--start-group $ARCHIVES -Wl,--end-group $_LIBDIRFLAGS $_LIBFLAGS -pthread -o $TARGET'
return env

NOTE2: This fix is tested only on Ubuntu 14.04 LTS (64bit) and might not work correctly in other systems. Please, try to use scons normally (without changing Sconstruct) before trying this method.

[Jon Rafkind]

1. I enabled a bug tracking feature on the sf paintown page, so you can use that.
2. The caching system doesn't just copy files from the data directory to the cache directory. The original mugen files are parsed into an internal format and the parsed version is saved in the cache. The files you copied are just ignored.
3. Adding -pthread should not be required. Probably you just have to do 'make clean' and it will rebuild just fine.

I'm still not sure what caused your original issue.

[Nobun]

1. Thank. I reported the 3.6.0. bug I discovered (I don't know if you already knew it or not) and a second bug report (for 3.6.1) that is shortcut link to this discussion for more details

2. Yes I know (I see that the files copied there were changed to, probably, python scripts). But I tried that fix becouse, at first time, I thinked a possible problem on permissions. So, creating an existing "644" file could bypass any possible permission problem. This why that fix. However, when I tried 3.6.0 (deleting completely $HOME/.paintown) I had no problem, so there should be an issue somewhere on code

3. While I had no problem on compiling 3.6.1 version, originally I wasn't able to compile 3.6.0 version due to a linking problem

/usr/bin/ld: build/sdl/util/network/hawknl/libhawknl.a(err.o): undefined reference to symbol 'pthread_setspecific@@GLIBC_2.2.5'
//lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: DSO missing from command line

After some reasearch and tries, I found how to solve the linkage problem (and I add the -pthread flag on line 1407 rightly before -o $TARGET). So I cleared all the scons build cache and rebuild all by 0, this time successfully.
Probably it was a problem where -pthead flag were originally appended (as you know, when you use static libraries, linking order matters!) or it was a problem on my system.

Infact I have noted that there are some issues specific to my own system (perhaps becouse 64bit, perhaps becouse it has also 32bit libraries in order to be able to compile with -m32 flag).

But... more probably becouse, 64bit Ubuntu linux, use some paths that are different from default ones (ex. most of system libraries are place on /usr/lib/x86_64-linux-gnu instead of /usr/lib).

Infact, for example, 3.6.0 doesn't check any embeddable python, even if python-dev is installed on my system (so... python headers exists in my system).

Another fact I can say to you (don't know if it helps) is "lua" example.
If I try to build a program with lua library, I need to explicitly specific a -ldl (linking to libdl) after liblua.a to avoid linkage errors