Rev 12385 error

Trying to build your own version of Vega Strike and having problems? Unix users, paste your config.log here (stderr output alone is not helpful).
Post Reply
Str
Explorer
Explorer
Posts: 14
Joined: Mon Dec 24, 2007 6:19 pm

Rev 12385 error

Post by Str »

bootstrap-sh and configure with

--with-data-dir=/opt/vegastrike/data --with-png-inc=/usr/include/libpng12 --with-boost=system --with-python-version=2.5

went good, then got an error on compiling src/networking/lowlevel/vsnet_clientstate. I've attached a make 2>&1 tee'd compile.log and my config.log, on Debian GNU/Linux Testing running 2.6.24.2 self compiled.
You do not have the required permissions to view the files attached to this post.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

make clean, then rerun ./bootstrap.sh You're using GCC 4.2, so it should be impossible for you to compile with TR1's headers.

Make sure your config.h has the #ifndef _VSCONFIG_H_ directives at the top of the file and then recompile.
Ed Sweetman endorses this message.
Str
Explorer
Explorer
Posts: 14
Joined: Mon Dec 24, 2007 6:19 pm

Post by Str »

hm...

checking tr1/unordered_map usability... yes
checking tr1/unordered_map presence... yes
checking for tr1/unordered_map... yes

on configure still there - i'll do a sysupdate soon, so i'll be able to compile with gcc 4.3, but maybe this configure test is somewhat broken when i shouldn't be able to compile with 4.2
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

the configure script will still check for it and find it. But the header will not use it if the gcc versions dont match.



First off, do an svn status and make sure you dont have any "M"'s showing up. This may cause conflicts to occur and thus your files wont be updated.

Then do an svn update to double check that you are using 12385.

Then do a make distclean. This will remove all generated files both by make and by autoconf.

Then rerun /bootstrap.sh

Now check config.h.in and see that at the top of the file you have
#ifndef _VSCONFIG_H_
#define _VSCONFIG_H_

If so then continue with your ./configure like you normally would.

Then compile

Then tell me what errors you get because you should be using regular hash_map and not including any tr1/unordered_map headers.

Ignore the configure check for unordered_map, just because it looks for it and finds it, doesn't mean we're actually using it.
Ed Sweetman endorses this message.
Str
Explorer
Explorer
Posts: 14
Joined: Mon Dec 24, 2007 6:19 pm

Post by Str »

Sorry, didnt had much time the last days..

I forgot to do that before a system update, that was anyway overdue, now i'm having gcc 4.3, and of course it works.

Anyway, could this have been a result of some Owner Problems? I did a chown -R 0:0 * (i'm in /opt) after seeing that some files had weird ownerships... (which were my fault of course :?)

The config.h.in file was fine.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

I'm almost sure your config.h hadn't been replaced with the newer one that would only allow it to be included once, rather than as many times as referenced. Whether that was due to permission issues or because you didn't properly remove all generated output and re-generate it, is unknown.


The only thing that should be using TR1's unordered_map is gcc 4.3 or higher. Any other compiler (less the win32 people setup the defines correctly for their compilers) should not get passed the ifdef's that look at the GCC version. The problem people were experiencing was due to config.h in automake land (cmake users were unaffected), did not include a #ifndef _CONFIG_H_ #define _CONFIG_H #endif wrapper. Thus undef'ing the variable used to determine if we have found unordered_map only worked for the first include of config.h, subsequent includes re-defined it. I fixed this by telling auto-tools to generate the correct wrapper to only permit 1 inclusion of config.h at a time.

Those using gcc 4.3 or above, shouldn't notice any difference in performance or behavior. If you do, i'd be _very_ interested in hearing about it. It's quite likely i missed something important in moving to unordered_map.... as it is not supposed to be a direct drop in replacement for hash_map, it just so happens that much is similar.
Ed Sweetman endorses this message.
Post Reply