Compiling on FreeBSD

[AMDmi3]

Hi!

I'm porting Vega Strike to FreeBSD and I run into some compile problems. I've searched through the forum and found that there were similar problems on Gentoo, but didn't find the solution. Maybe some of developers can give a clue on what's wrong? Seems like some weird namespace collision magic to me (maybe due to mixing C/C++ headers) or something like that.

Full buildlog and config.log here: http://amdmi3.ru/vegastrike/

Code: Select all

        g++ -DHAVE_CONFIG_H -I.   -I./boost/1_33 -I/usr/local/include   -DHAVE_SDL=1 -DSDL_WINDOWING=1      -DHAVE_AL=1 -I/usr/local/include  -DHAVE_OGG   -I/usr/local/include/python2.5 -DHAVE_PYTHON=1    -I./src   -pipe   -I/usr/local/include/SDL -I/usr/local/include -D_GNU_SOURCE=1 -D_REENTRANT -pthread -MT src/cmd/ai/docking.o -MD -MP -MF $depbase.Tpo -c -o src/cmd/ai/docking.o src/cmd/ai/docking.cpp &&\
        mv -f $depbase.Tpo $depbase.Po
In file included from /usr/include/c++/4.2/ios:47,
                 from /usr/include/c++/4.2/ostream:45,
                 from /usr/include/c++/4.2/iterator:70,
                 from /usr/include/c++/4.2/ext/hashtable.h:69,
                 from /usr/include/c++/4.2/ext/hash_map:65,
                 from ./src/gnuhash.h:21,
                 from ./src/hashtable.h:25,
                 from ./src/python/python_compile.h:8,
                 from src/cmd/ai/docking.cpp:2:
/usr/include/c++/4.2/bits/localefwd.h:58:34: error: macro "isspace" passed 2 arguments, but takes just 1
/usr/include/c++/4.2/bits/localefwd.h:70:34: error: macro "isupper" passed 2 arguments, but takes just 1
/usr/include/c++/4.2/bits/localefwd.h:74:34: error: macro "islower" passed 2 arguments, but takes just 1
/usr/include/c++/4.2/bits/localefwd.h:78:34: error: macro "isalpha" passed 2 arguments, but takes just 1
/usr/include/c++/4.2/bits/localefwd.h:94:34: error: macro "isalnum" passed 2 arguments, but takes just 1
/usr/include/c++/4.2/bits/localefwd.h:102:34: error: macro "toupper" passed 2 arguments, but takes just 1
/usr/include/c++/4.2/bits/localefwd.h:106:34: error: macro "tolower" passed 2 arguments, but takes just 1
In file included from /usr/include/c++/4.2/bits/basic_ios.h:44,
                 from /usr/include/c++/4.2/ios:50,
                 from /usr/include/c++/4.2/ostream:45,
                 from /usr/include/c++/4.2/iterator:70,
                 from /usr/include/c++/4.2/ext/hashtable.h:69,
                 from /usr/include/c++/4.2/ext/hash_map:65,
                 from ./src/gnuhash.h:21,
                 from ./src/hashtable.h:25,
                 from ./src/python/python_compile.h:8,
                 from src/cmd/ai/docking.cpp:2:
/usr/include/c++/4.2/bits/locale_facets.h:242:53: error: macro "toupper" passed 2 arguments, but takes just 1
/usr/include/c++/4.2/bits/locale_facets.h:271:53: error: macro "tolower" passed 2 arguments, but takes just 1
/usr/include/c++/4.2/bits/locale_facets.h:814:53: error: macro "toupper" passed 2 arguments, but takes just 1
/usr/include/c++/4.2/bits/locale_facets.h:847:53: error: macro "tolower" passed 2 arguments, but takes just 1
/usr/include/c++/4.2/bits/locale_facets.h:4611:44: error: macro "isspace" passed 2 arguments, but takes just 1
/usr/include/c++/4.2/bits/locale_facets.h:4629:44: error: macro "isupper" passed 2 arguments, but takes just 1
/usr/include/c++/4.2/bits/locale_facets.h:4635:44: error: macro "islower" passed 2 arguments, but takes just 1
/usr/include/c++/4.2/bits/locale_facets.h:4641:44: error: macro "isalpha" passed 2 arguments, but takes just 1
/usr/include/c++/4.2/bits/locale_facets.h:4665:44: error: macro "isalnum" passed 2 arguments, but takes just 1
/usr/include/c++/4.2/bits/locale_facets.h:4677:44: error: macro "toupper" passed 2 arguments, but takes just 1
/usr/include/c++/4.2/bits/locale_facets.h:4683:44: error: macro "tolower" passed 2 arguments, but takes just 1
In file included from /usr/include/c++/4.2/ios:47,
                 from /usr/include/c++/4.2/ostream:45,
                 from /usr/include/c++/4.2/iterator:70,
                 from /usr/include/c++/4.2/ext/hashtable.h:69,
                 from /usr/include/c++/4.2/ext/hash_map:65,
                 from ./src/gnuhash.h:21,
                 from ./src/hashtable.h:25,
                 from ./src/python/python_compile.h:8,
                 from src/cmd/ai/docking.cpp:2:
/usr/include/c++/4.2/bits/localefwd.h:58: error: 'std::isspace' declared as an 'inline' variable
/usr/include/c++/4.2/bits/localefwd.h:58: error: template declaration of 'bool std::isspace'
/usr/include/c++/4.2/bits/localefwd.h:70: error: 'std::isupper' declared as an 'inline' variable
/usr/include/c++/4.2/bits/localefwd.h:70: error: template declaration of 'bool std::isupper'
/usr/include/c++/4.2/bits/localefwd.h:74: error: 'std::islower' declared as an 'inline' variable
/usr/include/c++/4.2/bits/localefwd.h:74: error: template declaration of 'bool std::islower'
/usr/include/c++/4.2/bits/localefwd.h:78: error: 'std::isalpha' declared as an 'inline' variable
/usr/include/c++/4.2/bits/localefwd.h:78: error: template declaration of 'bool std::isalpha'
/usr/include/c++/4.2/bits/localefwd.h:94: error: 'std::isalnum' declared as an 'inline' variable
/usr/include/c++/4.2/bits/localefwd.h:94: error: template declaration of 'bool std::isalnum'
/usr/include/c++/4.2/bits/localefwd.h:102: error: 'std::toupper' declared as an 'inline' variable
/usr/include/c++/4.2/bits/localefwd.h:102: error: template declaration of '_CharT std::toupper'
/usr/include/c++/4.2/bits/localefwd.h:106: error: 'std::tolower' declared as an 'inline' variable
/usr/include/c++/4.2/bits/localefwd.h:106: error: template declaration of '_CharT std::tolower'
In file included from /usr/include/c++/4.2/bits/basic_ios.h:44,
                 from /usr/include/c++/4.2/ios:50,
                 from /usr/include/c++/4.2/ostream:45,
                 from /usr/include/c++/4.2/iterator:70,
                 from /usr/include/c++/4.2/ext/hashtable.h:69,
                 from /usr/include/c++/4.2/ext/hash_map:65,
                 from ./src/gnuhash.h:21,
                 from ./src/hashtable.h:25,
                 from ./src/python/python_compile.h:8,
                 from src/cmd/ai/docking.cpp:2:
/usr/include/c++/4.2/bits/locale_facets.h:227: error: 'btowc' is not a type
/usr/include/c++/4.2/bits/locale_facets.h:242: error: expected ';' before 'const'
/usr/include/c++/4.2/bits/locale_facets.h:255: error: expected `;' before 'char_type'
/usr/include/c++/4.2/bits/locale_facets.h:256: error: 'btowc' is not a type
/usr/include/c++/4.2/bits/locale_facets.h:271: error: expected ';' before 'const'
/usr/include/c++/4.2/bits/locale_facets.h:287: error: expected `;' before 'char_type'
/usr/include/c++/4.2/bits/locale_facets.h: In member function '_CharT std::__ctype_abstract_base<_CharT>::towupper(int (*)(_CharT)) const':
/usr/include/c++/4.2/bits/locale_facets.h:228: error: '__c' was not declared in this scope
/usr/include/c++/4.2/bits/locale_facets.h: In member function '_CharT std::__ctype_abstract_base<_CharT>::towlower(int (*)(_CharT)) const':
/usr/include/c++/4.2/bits/locale_facets.h:257: error: '__c' was not declared in this scope
/usr/include/c++/4.2/bits/locale_facets.h: At global scope:
/usr/include/c++/4.2/bits/locale_facets.h:797: error: 'btowc' is not a type
/usr/include/c++/4.2/bits/locale_facets.h:814: error: expected ';' before 'const'
/usr/include/c++/4.2/bits/locale_facets.h:829: error: expected `;' before 'char_type'
/usr/include/c++/4.2/bits/locale_facets.h:830: error: 'btowc' is not a type
/usr/include/c++/4.2/bits/locale_facets.h:847: error: expected ';' before 'const'
/usr/include/c++/4.2/bits/locale_facets.h:866: error: expected `;' before 'char_type'
/usr/include/c++/4.2/bits/locale_facets.h: In member function 'char std::ctype<char>::towupper(int (*)(char)) const':
/usr/include/c++/4.2/bits/locale_facets.h:798: error: '__c' was not declared in this scope
/usr/include/c++/4.2/bits/locale_facets.h: In member function 'char std::ctype<char>::towlower(int (*)(char)) const':
/usr/include/c++/4.2/bits/locale_facets.h:831: error: '__c' was not declared in this scope
In file included from /usr/include/c++/4.2/bits/basic_ios.h:44,
                 from /usr/include/c++/4.2/ios:50,
                 from /usr/include/c++/4.2/ostream:45,
                 from /usr/include/c++/4.2/iterator:70,
                 from /usr/include/c++/4.2/ext/hashtable.h:69,
                 from /usr/include/c++/4.2/ext/hash_map:65,
                 from ./src/gnuhash.h:21,
                 from ./src/hashtable.h:25,
                 from ./src/python/python_compile.h:8,
                 from src/cmd/ai/docking.cpp:2:
/usr/include/c++/4.2/bits/locale_facets.h: At global scope:
/usr/include/c++/4.2/bits/locale_facets.h:4611: error: function definition does not declare parameters
/usr/include/c++/4.2/bits/locale_facets.h:4629: error: function definition does not declare parameters
/usr/include/c++/4.2/bits/locale_facets.h:4635: error: function definition does not declare parameters
/usr/include/c++/4.2/bits/locale_facets.h:4641: error: function definition does not declare parameters
/usr/include/c++/4.2/bits/locale_facets.h:4665: error: function definition does not declare parameters
/usr/include/c++/4.2/bits/locale_facets.h:4677: error: function definition does not declare parameters
/usr/include/c++/4.2/bits/locale_facets.h:4683: error: function definition does not declare parameters
gmake[1]: *** [src/cmd/ai/docking.o] Error 1
gmake[1]: Leaving directory `/usr/home/amdmi3/projects/ports/vegastrike/vegastrike-0.5.0'
gmake: *** [all] Error 2

[ace123]

everything seems to be because of this 'locale_facets.h' file. Probably is caused by one really simple error... no specific reason it shouldn't work on FreeBSD.

Weird thing is that I have GCC 4.2, but I haven't seen these errors--maybe it's not the default compiler yet.

[safemode]

i use 4.2 just fine. functions are using the wrong number of arguments and such, the compiler has nothing to do with that, as I use gcc 4.2 and have no such issues. It's gotta be a macro not getting defined allowing the external instances of those functions getting used rather than some other implementation.

[AMDmi3]

Well, googling this error gives, for example, this:

http://gcc.gnu.org/ml/gcc/2002-05/msg02124.html

Though I couldn't reproduce this with simple helloworld with different combination of #includes.

We could try to compare `grep -R isspace /usr/include`. Here's mine:

Code: Select all

% grep -R isspace /usr/include      
/usr/include/c++/4.2/bits/localefwd.h:    isspace(_CharT, const locale&);
/usr/include/c++/4.2/bits/locale_facets.h:    isspace(_CharT __c, const locale& __loc)
/usr/include/c++/4.2/cctype:#undef isspace
/usr/include/c++/4.2/cctype:  using ::isspace;
/usr/include/c++/4.2/iosfwd:#include <cctype>           // For isspace, etc.
/usr/include/netinet/ip_compat.h:#define        ISSPACE(x)      isspace((u_char)(x))
/usr/include/netinet/ip_proxy.h:#ifndef isspace
/usr/include/netinet/ip_proxy.h:#define isspace(x)      (((x) == ' ') || ((x) == '\r') || ((x) == '\n') || \
/usr/include/sys/ctype.h:#define isspace(c)     ((c) == ' ' || ((c) >= '\t' && (c) <= '\r'))
/usr/include/ctype.h:int        isspace(int);
/usr/include/ctype.h:#define    isspace(c)      __sbistype((c), _CTYPE_S)
/usr/include/stand.h:static __inline int isspace(int c)

[safemode]

localefwd is apparently your problem. It seems to be out of sync with the ctype version of the function. I would look into why localefwd is being used, or if it's an issue with your fbsd's pkg for gcc, perhaps getting things out of sync. i'm not home to check my copy of debian's gcc to see what it says about isspace's definitions.

it seems localefwd is suppose to wrap the real isspace, but somehow we're overriding it in headers ... and this isn't the case in linux/windows/mac land. I'm leaning towards an issue in your dev environment or a missing macro conditional during your porting to bsd.

[safemode]

> A solution (as already posted in april 2005) is to #undef the isspace
> macro. But with all these nested includes it's hard to get a good
> overview of what is included when, so maybe you could try putting this
> at the top of the c++ file that has the compile error:
>
> #include <ctype.h>
> #undef isspace
>
> ctype.h won't be included again because of the #ifndef _CTYPE_H_ /
> #define _CTYPE_H_ stuff, so hopefully the isspace macro then won't be
> defined again either.



We need to track down why this occurs though. Just another example of the include mess we have from 10 years of hacking.

[AMDmi3]

Actually I've just fixed it. In the end I've remembered I had similar problem with another game - the problem is likely in Python headers (and it seems FreeBSD specific). The fix is to move python-related includes before all others in src/cmd/ai/docking.cpp and src/python/universe_util_export.cpp.

After those two I had another issue with src/cmd/collide2/opcodetypes.h: it complained to redefinition of wint_t and wchar_t. On FreeBSD those are defined like this (wchar.h):

Code: Select all

#ifndef __cplusplus
#ifndef _WCHAR_T_DECLARED
typedef __wchar_t       wchar_t;
#define _WCHAR_T_DECLARED
#endif
#endif

#ifndef _WINT_T_DECLARED
typedef __wint_t        wint_t;
#define _WINT_T_DECLARED
#endif

so _WCHAR_T_DECLARED and _WINT_T_DECLARED should be checked in opcodetypes.h. But because of that #ifndef __cplusplus, _WCHAR_T_DECLARED won't work, so I've just commented out typedefs. Now it compiled successfully, so I turn to testing how it actually runs.

[safemode]

you aren't setting HAVE_WCHAR_H in your config.h file that gets generated by autotools in linux.

hopefully this crap will get resolved if we move over to cmake.



edit: apparently the checks are vestigial to CS. VS, we assume you have wchar.h. I Will remove the macro checks at the bottom of the file when i get home. I'll also fix the ordering of the headers in those two files too. Keep us up to date about any other build related issues involved with bsd compiling. It'd be nice to add it to the list of supported OS's. Though, with kfreebsd, bsd support shouldn't be hard.

[AMDmi3]

you aren't setting HAVE_WCHAR_H in your config.h file that gets generated by autotools in linux.

Actually I am, HAVE_WCHAR_H and HAVE_WCTYPE_H are there

But, because

Code: Select all

typedef __wchar_t       wchar_t;
#define _WCHAR_T_DECLARED

lines are wrapped in "#ifndef __cplusplus" for some reason, there's no way to check for _WCHAR_T_DECLARED. I guess.

hopefully this crap will get resolved if we move over to cmake.

edit: apparently the checks are vestigial to CS. VS, we assume you have wchar.h. I Will remove the macro checks at the bottom of the file when i get home. I'll also fix the ordering of the headers in those two files too. Keep us up to date about any other build related issues involved with bsd compiling. It'd be nice to add it to the list of supported OS's. Though, with kfreebsd, bsd support shouldn't be hard.

Cool, thanks for you support. CMake will also be very good. I'll do my best to make it work on FreeBSD, and it's already halfway done since it compiles successfully :)

[ace123]

Ah--Makes sense that those headers won't redefine wchar_t in C++.

The C++98 standard makes wchar_t a built-in type, so indeed the problematic line is the one in opcodetypes.h -- nothing need be defined for wchar_t to exist, and I don't think we even support old compilers like MSVC6... maybe we can have configure set WCHAR_NEEDS_DEFINING for old/broken compilers.

I'll try to commit a fix to this tonight-- I'm surprised that only two cpp files had issues with ordering of the includes.

Python headers are really nasty -- they make some really stupid assumptions about the compiler/system and I wasted a few hours the last week trying to make them work when cross-compiling to 32-bit.

[safemode]

I was just gonna remove the code from opcodetypes.h if you want to make a fix that works with old out-dated compilers ....then ok..i'll not do anything to the file so it doesn't conflict.

[ace123]

Go ahead and remove it...
I was suggesting that such a fix could be possible if necessary--but personally, I don't care about anything before GCC 3.3

If compiling does break for some people then we can try and figure out a solution in ./configure to basically check if wchar_t is defined by default.

[AMDmi3]

Well, it works, though very slow (8..20 FPS) on my p4-1.7, 512Mb, GeForce3 64Mb, although only visible things are gui, planet and background (high detail, shaders off, 512ram+1Gb swap settings). It also took pretty long time to load. Also fonts are distorted in 1280x1024 resolution.

Anyway, that's out of porting scope (unless some of those are FreeBSD specific). What I need to do next is to make VS installable systemwide (for now it works from source directory). I guess I need to install whole vegastrike-linux tarball except for bin/ directory into (common in FreeBSD) /usr/local/share/vegastrike and compiled binaries into /usr/local/bin. The question is how to specify custom datadir setting for compilation?

Also, I plan to add some user-toggleable options to the port, so user could disable some features he doesn't need and thus have faster compilation and less dependencies required. I guess there's no sense to make vssetup optional, but --disable-ogre, --disable-cegui and --disable-ffmpeg seem interesting. Ogre is only needed for mesher modelling tool, right? And where is cegui and ffmpeg used? Is there a sense to make those optional?

[safemode]

if you have vsync on it'll load slow. If your graphics card is not hardware accelerated it'll be slow. Finally, I'd suggest a graphics card at the most 5 years old. That one is very weak, i'm surprised it got 20fps for any given period of time.

data dir can be set in the vegastrike.config file, it also has many default searches. see vsfilesystem.cpp for some of the defaults.

everything that is in the configure script to enable and disable are optional, by their nature.

I was hoping we'd be able to push your changes into VS... but if you're making some kind of custom makefile rather than utilize the autoconf system in place I dont see that happening. Eventually we'll move to cmake i think, which should make any OS specific build changes a non-issue.

[AMDmi3]

if you have vsync on it'll load slow.

I don't

If your graphics card is not hardware accelerated it'll be slow. Finally, I'd suggest a graphics card at the most 5 years old. That one is very weak, i'm surprised it got 20fps for any given period of time.

I agree it's rather old, but it still works pretty well with all OpenGL games I've tried (well, xmoto, quake3, sauerbraten, glest and many others). It's quite hard to believe that open space requires much more rendering power than those.

see vsfilesystem.cpp for some of the defaults.

That's what I need, thanks.

everything that is in the configure script to enable and disable are optional, by their nature.

The question is where/for what exactly are cegui and ffmpeg used, and is there a sense to turn them off for average game user. For example, it won't make sense to make cegui optional if it's used for game gui (user won't have gui otherwise?), but it makes sense to make ffmpeg optional if it's only used for (for example) saving ingame videos.

I was hoping we'd be able to push your changes into VS... but if you're making some kind of custom makefile rather than utilize the autoconf system in place I dont see that happening. Eventually we'll move to cmake i think, which should make any OS specific build changes a non-issue.

Well, FreeBSD ports are essentially Makefiles, yes, but they're only wrappers around native build systems (autotools or cmake or scons or whatever). In this case the port is just unpacking tarball(s), applying some patches, and executing configure and make. Usually it also executes make install, but in the case of VS data won't be installed (since there's no data in source tarball), so the port needs to install it itself. So of course it's the best to integrate all changes needed to make it run on FreeBSD upstream and make port do as little work as possible.

In the case of data, usual approach is to either integrate it into source tarball, so `make install` will just install everything into right locations or to provide data tarball separately from both source and binary packages. I like the latter more, as data usually changes less frequent than source, so multiple versions of program can use same data package. Less downloads, less diskspace taken, faster updating etc.

[loki1950]

You could turn off support for cegui it is not used yet wll be used when we finally get OGRE3d and support for ffmpeg can also be turned off more for cut scenes that game sequences but no cut scenes yet either. should trim the symbol table a bit.

Enjoy the Choice

[AMDmi3]

Now I'm almost done withe the port. The last issue is dotdir handling. Seems like vssetup (and vegastrike as well, I assume) don't use dotdir by default, so vssetup segfaults like this:

Code: Select all

% vssetup    
Found data in /usr/local/share/vegastrike
Unable to write  to vegastrike.config
[1]    29876 segmentation fault  vssetup

First question: there are .vegastrike directory in data SVN and .vegastrike-0.5.0 in linux tarball - what are those? Are those needed as default content for dotdir or those are just leftovers from unclear packaging?

Next: what will be the correct way to make it use ~/.vegastrike for storing config (and perhaps other data)? If VS works like "cd into datadir and read/write all data there" possible hack is to add code to create ~/.vegastrike and populate it with symlinks to data directories and copies of changeable files. If you guys are planning to add dotdir support anytime soon I can wait with submitting the port or help with that.

[AMDmi3]

Btw, those are patches I've used to make it compile: http://amdmi3.ru/vegastrike/

[loki1950]

The .vegastrike directory should be created in your home directory that is where any user preferences (the active copy of vegastrike.config) and the save game files are stored.it should be created when you run vssetup so if it is not being created something is wrong. I know that if you run VS in userland as i do with the svn it is necessary to remove .temp from the copy of vegastrike.config in ~/.vegastrike otherwise it uses the version in the data tree the .vegastrike folder in the data should be copied to your Home.
If this is not clear please post any further questions

Enjoy the Choice

[safemode]

those patches will no longer be necessary when i merge my branch to svn head. I have all those fixes.

[AMDmi3]

it should be created when you run vssetup so if it is not being created something is wrong.

I'll investigate it further tomorrow.

those patches will no longer be necessary when i merge my branch to svn head. I have all those fixes.

I understood. That was just in case.

[ace123]

Not sure if you already figured this out, but the way it knows where the data directory is supposed to be is by reading the symlink where the binary is (though the way this works is somewhat platform specific).
So you can store binaries in vegastrike/bin and symlink them to /usr/local/bin

If that doesn't work in FreeBSD, the other option is to make shellscript wrappers that call the ones in the game directory.

You can also use the --with-data-dir=SOMEPATH option as a last resort...
Though I believe this overrides all other tests and would be hardcoded in the binary--you may want to fix the order defined in vsfilesystem.cpp line ~563

So the order it currently looks for files is:
1. Hardcoded data path (if any)
2. Current directory/, current directory/../, ../data/, etc.
3. binary directory/, binary directory/../, etc.

I made sure vssetup, vegastrike and vegaserver all used the same function for locating the data directories (old versions of VS had a lot of confusion about this).

[ace123]

Your home directory location is found in "Version.txt" which must exist in the data directory. For the release it was named ".vegastrike-0.5.0"

In vegastrike, it first looks for vegastrike.config in your home directory, and only if one does not exist there it goes to the data directory.

In vssetup, it will use the newer of the one in your home dir and the data dir (that way, it can load defaults, and can also update what is in the home directory if the data directory has changed).

EDIT: it should not have segfaulted or attempted to write to the data dir... how did you invoke it? You can try strace'ing it, writing stderr to a file to see where it's writing to...

[AMDmi3]

In vssetup, it will use the newer of the one in your home dir and the data dir (that way, it can load defaults, and can also update what is in the home directory if the data directory has changed).

So it's correct for .vegastrike-0.5.0 to exist in the datadir and vssetup/vegastrike won't attempt to write there?

EDIT: it should not have segfaulted or attempted to write to the data dir... how did you invoke it? You can try strace'ing it, writing stderr to a file to see where it's writing to...

It segfaults when I change any value in the dialog.
~/.vegastrike-0.5.0 isn't created, but vegastrike.config.temp appears in ~. If I create ~/.vegastrike-0.5.0 beforehand, vegastrike.config.temp appears there insted, but vssetup still segfaults.

Here's the backtrace:

Code: Select all

#0  0x0000000803e28ee0 in strchr () from /lib/libc.so.7
#1  0x0000000803e2c7f0 in vfprintf () from /lib/libc.so.7
#2  0x0000000803e1c1d0 in fprintf () from /lib/libc.so.7
#3  0x00000000004084db in Modconfig ()
#4  0x0000000000408582 in DisableSetting ()
#5  0x0000000000406e1d in ClickButton ()
#6  0x00000008021642ca in g_closure_invoke () from /usr/local/lib/libgobject-2.0.so.0
#7  0x00000008021764e1 in g_signal_handler_disconnect () from /usr/local/lib/libgobject-2.0.so.0
#8  0x0000000802177e37 in g_signal_emit_valist () from /usr/local/lib/libgobject-2.0.so.0
#9  0x00000008021781c2 in g_signal_emit () from /usr/local/lib/libgobject-2.0.so.0
#10 0x000000080086dbac in gtk_widget_activate () from /usr/local/lib/libgtk-x11-2.0.so.0
#11 0x0000000800784145 in gtk_menu_shell_activate_item () from /usr/local/lib/libgtk-x11-2.0.so.0
#12 0x00000008007858fa in gtk_menu_shell_append () from /usr/local/lib/libgtk-x11-2.0.so.0
#13 0x0000000800778f91 in gtk_marshal_BOOLEAN__VOID () from /usr/local/lib/libgtk-x11-2.0.so.0
#14 0x00000008021642ca in g_closure_invoke () from /usr/local/lib/libgobject-2.0.so.0
#15 0x00000008021768bf in g_signal_handler_disconnect () from /usr/local/lib/libgobject-2.0.so.0
#16 0x0000000802177b4e in g_signal_emit_valist () from /usr/local/lib/libgobject-2.0.so.0
#17 0x00000008021781c2 in g_signal_emit () from /usr/local/lib/libgobject-2.0.so.0
#18 0x0000000800869ee8 in gtk_widget_get_default_style () from /usr/local/lib/libgtk-x11-2.0.so.0
#19 0x0000000800773c4c in gtk_propagate_event () from /usr/local/lib/libgtk-x11-2.0.so.0
#20 0x000000080077498a in gtk_main_do_event () from /usr/local/lib/libgtk-x11-2.0.so.0
#21 0x0000000800afe3a1 in gdk_add_client_message_filter () from /usr/local/lib/libgdk-x11-2.0.so.0
#22 0x00000008023cd1ca in g_main_context_dispatch () from /usr/local/lib/libglib-2.0.so.0
#23 0x00000008023cffbe in g_main_context_check () from /usr/local/lib/libglib-2.0.so.0
#24 0x00000008023d0281 in g_main_loop_run () from /usr/local/lib/libglib-2.0.so.0
#25 0x0000000800774cf9 in gtk_main () from /usr/local/lib/libgtk-x11-2.0.so.0
#26 0x00000000004072d8 in ShowMain ()
#27 0x0000000000406bbc in Start ()
#28 0x0000000000405995 in main ()

[safemode]

make sure your vegastrike.config is unchanged from svn.

The core to the problem is in why the user dir isn't created. Though, we do have an unfixed issue with the config in at least linux land where the config file is in a state upon fresh install that causes the vssetup program to not make any changes to the config files. black magic is required to jump start it to actually write changes to the user file. another reason why we need a new config app.



I wouldn't worry about the segfault until we figure out why you dont get the correct user dir created.