Wadgen fails if run on a ROM in the current directory when run over SSH

[mdeguzis]

With doom.z64 in PWD:

doom64ex -wadgen doom64.z64 
...
Writing IWAD File...
ERROR: File_Open: Couldn't create doom64.z64/doom64.wad

In another directory:

mkdir output_wad && cd output_wad
doom64ex -wadgen ../doom64.z64 
...
Sucessfully created ../doom64.wad
Writing Soundfont File...

Sucessfully created ../doomsnd.sf2

Probably something to do with XDG_DATA_HOME not being set on my VPS. It may be nice to have a fallback if this scenario occurs. Just something I noticed.

[pinkwah]

Thanks. I intend to start refactoring Wadgen after I get done setting up nightly builds. (Shouldn't take too long.)

[mdeguzis]

Np, just checking, since I was unsure of the intricate behavior here. Thanks for looking at this. Did you see my other message about c++11 vs c++14 features?

[pinkwah]

You mean the one about clang 3.6? Yeah. I'm currently in the process of setting up a travis-ci config. They run Ubuntu 12.04 (precise) build VMs, so that should inform us of what the minimum versions of gcc and clang are.

[pinkwah]

So it seems that GCC 5 and Clang 3.5 with libstdc++-5 (usually installed alongside GCC 5) are the minimum compiler versions needed to compile this thing.

I couldn't find a backport of libc++ (Clang's version of libstdc++), but I imagine it will work as well.

[mdeguzis]

You can specify a CXX flagset like -DCMAKE_CXX_FLAGS="-O2 -g -stdlib=libc++ to use that.

[pinkwah]

Yes, I know. But I didn't manage to install libc++ in either my 12.04 VM or travis (which is also 12.04). Seems like the llvm repo doesn't have it or something.

The packages in question are called: libc++-dev and libc++abi-dev.

[pinkwah]

The current wadgen uses the standard fopen/fwrite/fclose functions instead of POSIX and puts the files into $XDG_DATA_DIR/doom64ex instead of wherever it wants.

Hopefully this solves the problem in OP.