Compiling on Linux (2bdc01f)

[tomreyn]

Based on this post I assume you'd like someone to try compiling Mandate on Linux and to report back on it. So I tried to compile it on my atibox (see below for specifications).

I prepared as follows:

Code: [Select]

cd /home/tomreyn/SCM/mandate
git pull

... made sure I hav the latest code

Code: [Select]

$ git show -s --format=%H
2bdc01fd50caf7f602285760d03e44d286fac9cb

... and built

Code: [Select]

rm -rf build; mkdir build; cd build
cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX='' ..
make -j4

cmake returned this:
http://paste.debian.net/11170/

make returned this:
http://pastebin.com/hPhNx3sa

[MoLAoS]

I wasn't asking for a tester, I just didn't understand why you thought it was windows only.

I don't really know what those errors means. It doesn't look much like the errors from VC++.

Does it say there are two errors?

Did you try compiling the latest version of GAE from GitHub on the same machine? It would be helpful to know if it was a pre existing problem. IIRC john had a problem with both GAE and Mandate when he tried to compile.

It looks like you are having some problem with fpermissive? Presumably because VC++ isn't standards compliance?

[tomreyn]

I wasn't asking for a tester, I just didn't understand why you thought it was windows only.

I'd say a project you only build on a single platform can't be really considered to be cross-platform, that's what made me say this. It should be fairly easy to setup a Linux VM on Windows nowadays, entirely with free and open source software. Grab a copy of VirtualBox and your favourite Linux distribution (Ubuntu and Debian can be good options), create a new VM, attach the Linux distro's installer image to its CD-ROM and install it. Or just use one of the many pre-installed "virtual appliances" out there (this gives you a headstart, but I wouldn't recommend it if this is going to be your development VM where you also create releases).

I don't really know what those errors means. It doesn't look much like the errors from VC++.

Different compiler. ;-)

Does it say there are two errors?

More like 15, but some of them may be follow-up errors.

The format of error messages is:

path to header file:line:column: error: error message

So if you search the output for the literal string ": error:" you will find them.

Did you try compiling the latest version of GAE from GitHub on the same machine? It would be helpful to know if it was a pre existing problem. IIRC john had a problem with both GAE and Mandate when he tried to compile.

I have tried now: 61f0c817b84d22077d6913269874b57b208a2034 built fine.

It looks like you are having some problem with fpermissive? Presumably because VC++ isn't standards compliance?

I'm not a programmer, but I guess that would explain those errors (but not the others).

[MoLAoS]

Okay. After googling it appears that GCC complains about certain things with const that VC++ doesn't care about. I have made a slight change that may solve the problem, although I can't be sure. Basically all the errors appear to be coming from 3 vectors:
UnitReq
ItemReq
UpgradeReq

In element_type.h

For w/e reason the vectors were:
<const thingy> thingies

So I've changed it to:
<thingy> thingies

I won't be able to say whether that was the issue until you recompile. Try and grab the new update from github to see if it works.

[tomreyn]

Indeed this fixed it, the build succeeded now (with loads of warnings).

And it even runs up to the main menu. As soon as I enter the options menu, though, GDB prints this:

Code: [Select]

Program received signal SIGSEGV, Segmentation fault.
Glest::Menu::MenuStateRoot::update (this=0x224e0f0) at /home/tomreyn/SCM/mandate/source/game/menu/menu_state_root.cpp:251
251                    ccState->getCharacterCreator()->loadTech();
(gdb) bt
#0  Glest::Menu::MenuStateRoot::update (this=0x224e0f0) at /home/tomreyn/SCM/mandate/source/game/menu/menu_state_root.cpp:251
#1  0x00000000006624be in Glest::Main::Program::loop (this=this@entry=0x7fffffffd3d0) at /home/tomreyn/SCM/mandate/source/game/main/program.cpp:331
#2  0x000000000065f476 in Glest::Main::glestMain (argc=argc@entry=1, argv=argv@entry=0x7fffffffe128) at /home/tomreyn/SCM/mandate/source/game/main/main.cpp:187
#3  0x000000000050a65d in main (argc=1, argv=0x7fffffffe128) at /home/tomreyn/SCM/mandate/source/game/main/main.cpp:220

When I decide to continue, it gives:

Code: [Select]

#0  0x00007ffff57023cd in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007ffff4267982 in poll (__timeout=-1, __nfds=1, __fds=0x7fffffffbd00) at /usr/include/x86_64-linux-gnu/bits/poll2.h:46
#2  _xcb_conn_wait (c=c@entry=0xa9fb00, cond=cond@entry=0x7fffffffbd70, vector=vector@entry=0x0, count=count@entry=0x0) at ../../src/xcb_conn.c:400
#3  0x00007ffff4268e57 in wait_for_reply (c=c@entry=0xa9fb00, request=2143, e=e@entry=0x7fffffffbe28) at ../../src/xcb_in.c:395
#4  0x00007ffff426907b in xcb_wait_for_reply (c=0xa9fb00, request=2143, e=0x7fffffffbe28) at ../../src/xcb_in.c:425
#5  0x00007ffff48db2d9 in _XReply () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#6  0x00007ffff7bbffb3 in DRI2GetBuffersWithFormat (dpy=0xa9e770, drawable=35651599, width=width@entry=0xfa37c8, height=height@entry=0xfa37cc, attachments=0x7fffffffbfc0, count=1, outCount=outCount@entry=0x7fffffffbfac) at dri2.c:485
#7  0x00007ffff7bbd78c in dri2GetBuffersWithFormat (driDrawable=<optimized out>, width=0xfa37c8, height=0xfa37cc, attachments=<optimized out>, count=<optimized out>, out_count=0x7fffffffbfac, loaderPrivate=0xfa36c0) at dri2_glx.c:893
#8  0x00007fffef2ce4d9 in dri2_drawable_get_buffers (count=<synthetischer Zeiger>, atts=0xfa3e80, drawable=0xfa37e0) at dri2.c:151
#9  dri2_allocate_textures (drawable=0xfa37e0, statts=0xfa3e80, statts_count=2) at dri2.c:402
#10 0x00007fffef2cd275 in dri_st_framebuffer_validate (stfbi=<optimized out>, statts=0xfa3e80, count=2, out=0x7fffffffc0f0) at dri_drawable.c:81
#11 0x00007fffee868006 in st_framebuffer_validate (stfb=stfb@entry=0xfa3a40, st=0xf9bc90, st=0xf9bc90) at ../../../../../src/mesa/state_tracker/st_manager.c:195
#12 0x00007fffee869515 in st_manager_validate_framebuffers (st=st@entry=0xf9bc90) at ../../../../../src/mesa/state_tracker/st_manager.c:832
#13 0x00007fffee83fe0c in st_validate_state (st=st@entry=0xf9bc90) at ../../../../../src/mesa/state_tracker/st_atom.c:172
#14 0x00007fffee84689a in st_Clear (ctx=0xf5cdc0, mask=18) at ../../../../../src/mesa/state_tracker/st_cb_clear.c:394
#15 0x000000000066251d in Glest::Main::Program::loop (this=this@entry=0x7fffffffd3d0) at /home/tomreyn/SCM/mandate/source/game/main/program.cpp:287
#16 0x0000000000662ddc in Glest::Main::Program::crash (this=0x7fffffffd3d0, e=e@entry=0x0) at /home/tomreyn/SCM/mandate/source/game/main/program.cpp:491
#17 0x000000000065facd in Glest::Main::ExceptionHandler::notifyUser (this=<optimized out>, pretty=<optimized out>) at /home/tomreyn/SCM/mandate/source/game/main/main.cpp:91
#18 0x00000000007aec86 in Shared::Platform::PlatformExceptionHandler::handler (signo=11, info=<optimized out>, context=<optimized out>) at /home/tomreyn/SCM/mandate/source/shared_lib/sources/platform/sdl/platform_util.cpp:262
#19 <signal handler called>
#20 Glest::Menu::MenuStateRoot::update (this=0x224e0f0) at /home/tomreyn/SCM/mandate/source/game/menu/menu_state_root.cpp:251
#21 0x00000000006624be in Glest::Main::Program::loop (this=this@entry=0x7fffffffd3d0) at /home/tomreyn/SCM/mandate/source/game/main/program.cpp:331
#22 0x000000000065f476 in Glest::Main::glestMain (argc=argc@entry=1, argv=argv@entry=0x7fffffffe128) at /home/tomreyn/SCM/mandate/source/game/main/main.cpp:187
#23 0x000000000050a65d in main (argc=1, argv=0x7fffffffe128) at /home/tomreyn/SCM/mandate/source/game/main/main.cpp:220

Accessing the "About" menu instead gives similar results.

Starting the game fresh from gdb, and heading to the new character editor menu you edit, gives this:

Code: [Select]

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff5fb55ee in std::string::assign(std::string const&) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(gdb) bt
#0  0x00007ffff5fb55ee in std::string::assign(std::string const&) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1  0x00000000005daaeb in operator= (__str=..., this=0x2468610) at /usr/include/c++/4.7/bits/basic_string.h:544
#2  Glest::Gui::CharacterCreator::setupListBoxTraits (this=this@entry=0x24667d0) at /home/tomreyn/SCM/mandate/source/game/game/character_creator.cpp:783
#3  0x00000000005db232 in Glest::Gui::CharacterCreator::buildSovereignTab (this=this@entry=0x24667d0) at /home/tomreyn/SCM/mandate/source/game/game/character_creator.cpp:123
#4  0x00000000005dc299 in Glest::Gui::CharacterCreator::buildTabs (this=0x24667d0) at /home/tomreyn/SCM/mandate/source/game/game/character_creator.cpp:67
#5  0x0000000000672e00 in Glest::Menu::MenuStateRoot::update (this=0x2075b90) at /home/tomreyn/SCM/mandate/source/game/menu/menu_state_root.cpp:252
#6  0x00000000006624be in Glest::Main::Program::loop (this=this@entry=0x7fffffffd3d0) at /home/tomreyn/SCM/mandate/source/game/main/program.cpp:331
#7  0x000000000065f476 in Glest::Main::glestMain (argc=argc@entry=1, argv=argv@entry=0x7fffffffe128) at /home/tomreyn/SCM/mandate/source/game/main/main.cpp:187
#8  0x000000000050a65d in main (argc=1, argv=0x7fffffffe128) at /home/tomreyn/SCM/mandate/source/game/main/main.cpp:220

[MoLAoS]

That was my bad. That is a bug on all compilers. I simply never checked those pages. I also fixed another bug in the xml cause of testing that bug. Unless something else weird happens it looks like it should compile on linux. You sure get a lot of warnings though.

Redownload and tell me it works. Honestly I'm shocked i managed to fix any errors because that compiler output was verbose and intense.

[tomreyn]

Menus work fine now (despite the way too slow mouse pointer, which I was able to work around using the RenderMouseCursorType=OSMouseCursor option).
Trying to start a game, it still freezes after printing this:

Code: [Select]

Deleting
~Cells
~Tileset
~TechTree
~World
~GameState...with the progress bar at 0%.

Terminal output:

Code: [Select]

[/home/tomreyn/.glestadv] is in the search path.
[/home/tomreyn/.glestadv/addons/project_red] is in the search path.
[/home/tomreyn/SCM/mandate/data/game] is in the search path.
config-dir: /home/tomreyn/.glestadv
data-dir: /home/tomreyn/SCM/mandate/data/game

Init Window: 0 ms.
Init OpenGL: 206 ms.
Load WidgetConfig: 430 ms.
Renderer Load Config: 0 ms.
Renderer Init Resources: 558 ms.
Renderer Load Shader: 36 ms.
Init Renderer: 840 ms.
Init Sound: 6 ms.
Renderer Init Menu: 0 ms.
ots/check / glest_classic/anarchy
ots/map / glest_classic/anarchy
Node "tech-tree" doesn't have 1 children named  "damage-types"

Tree: tech-tree (description attack-types (attack-type attack-type attack-type attack-type attack-type )  armor-types (armor-type armor-type armor-type armor-type armor-type armor-type )  damage-multipliers )
I have a feeling this might be an old GAE shortcoming (possibly texture compression related?) which a workaround existed for, but can't remember which.

It turns out that while the screen just freezes, it's actually a segmentation fault, so we've got a backtrace:

Code: [Select]

tomreyn@atibox:~/SCM/mandate$ gdb -q -n -ex "bt" -batch ./build/source/game/glestadv ~/.glestadv/core
[New LWP 21809]
[New LWP 21814]
[New LWP 21810]
[New LWP 21812]
[New LWP 21815]

warning: Can't read pathname for load map: input/output error.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7fffc495c000
Core was generated by `./build/source/game/glestadv'.
Program terminated with signal 11, Segmentation fault.
#0  0x00007f832812eaab in raise (sig=11) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:38
38    ../nptl/sysdeps/unix/sysv/linux/pt-raise.c: File or directory not found.
#0  0x00007f832812eaab in raise (sig=11) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:38
#1  0x00000000007aef1b in Shared::Platform::PlatformExceptionHandler::handler (signo=11, info=<optimized out>, context=<optimized out>) at /home/tomreyn/SCM/mandate/source/shared_lib/sources/platform/sdl/platform_util.cpp:282
#2  <signal handler called>
#3  Glest::Plan::GoalSystem::findLair (this=this@entry=0x7fffc4908148, unit=unit@entry=0x54617f0) at /home/tomreyn/SCM/mandate/source/game/ai_mandate/mandate_ai_personalities.cpp:1111
#4  0x000000000053d605 in Glest::Plan::MandateAISim::getTopGoal (this=this@entry=0x7fffc4908120, unit=unit@entry=0x54617f0, personality=...) at /home/tomreyn/SCM/mandate/source/game/ai_mandate/mandate_ai_sim.cpp:159
#5  0x000000000053dc4d in Glest::Plan::MandateAISim::computeAction (this=this@entry=0x7fffc4908120, unit=unit@entry=0x54617f0, personality=..., reason=...) at /home/tomreyn/SCM/mandate/source/game/ai_mandate/mandate_ai_sim.cpp:275
#6  0x000000000053eeb7 in Glest::Plan::MandateAISim::update (this=this@entry=0x7fffc4908120) at /home/tomreyn/SCM/mandate/source/game/ai_mandate/mandate_ai_sim.cpp:383
#7  0x0000000000788ca3 in Glest::Sim::SimulationInterface::updateWorld (this=0x435e250) at /home/tomreyn/SCM/mandate/source/game/world/sim_interface.cpp:252
#8  0x00000000005ef94d in Glest::Gui::GameState::update (this=0x4027ef0) at /home/tomreyn/SCM/mandate/source/game/game/game.cpp:325
#9  0x000000000066262e in Glest::Main::Program::loop (this=this@entry=0x7fffc4908370) at /home/tomreyn/SCM/mandate/source/game/main/program.cpp:331
#10 0x000000000065f5e6 in Glest::Main::glestMain (argc=argc@entry=1, argv=argv@entry=0x7fffc49090c8) at /home/tomreyn/SCM/mandate/source/game/main/main.cpp:187
#11 0x000000000050a7bd in main (argc=1, argv=0x7fffc49090c8) at /home/tomreyn/SCM/mandate/source/game/main/main.cpp:220

[MoLAoS]

That is my bad. Some of the content doesn't work.

You should only use the provision tech tree which should only have the humans faction. If you were already doing this there might be a bug.

[tomreyn]

Yes, I was trying this setup (amongst others). Indeed with the Provision tech tree the game does start (after initializing which involves a short period where the progress bar states that progress is now at some high negative value (integer foo?)). However, after starting up (where all game elements have been drawn, so you see some buildings and units and the HUD) it immediately switches to a screen which, again, prints this:

Code: [Select]

Deleting
~Cells
~Tileset
~TechTree
~World
(but not ~Gamestate this time) ... at which point the game freezes again.

Here, too, hitting Alt-F4 at this point will make it run into a segmentation fault:

Code: [Select]

Core was generated by `./build/source/game/glestadv'.
Program terminated with signal 11, Segmentation fault.
#0  0x00007f832812eaab in raise (sig=11) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:38
#0  0x00007f832812eaab in raise (sig=11) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:38
#1  0x00000000007aef1b in Shared::Platform::PlatformExceptionHandler::handler (signo=11, info=<optimized out>, context=<optimized out>) at /home/tomreyn/SCM/mandate/source/shared_lib/sources/platform/sdl/platform_util.cpp:282
#2  <signal handler called>
#3  Glest::Plan::GoalSystem::findLair (this=this@entry=0x7fffc4908148, unit=unit@entry=0x54617f0) at /home/tomreyn/SCM/mandate/source/game/ai_mandate/mandate_ai_personalities.cpp:1111
#4  0x000000000053d605 in Glest::Plan::MandateAISim::getTopGoal (this=this@entry=0x7fffc4908120, unit=unit@entry=0x54617f0, personality="defender") at /home/tomreyn/SCM/mandate/source/game/ai_mandate/mandate_ai_sim.cpp:159
#5  0x000000000053dc4d in Glest::Plan::MandateAISim::computeAction (this=this@entry=0x7fffc4908120, unit=unit@entry=0x54617f0, personality="defender", reason="compute") at /home/tomreyn/SCM/mandate/source/game/ai_mandate/mandate_ai_sim.cpp:275
#6  0x000000000053eeb7 in Glest::Plan::MandateAISim::update (this=this@entry=0x7fffc4908120) at /home/tomreyn/SCM/mandate/source/game/ai_mandate/mandate_ai_sim.cpp:383
#7  0x0000000000788ca3 in Glest::Sim::SimulationInterface::updateWorld (this=0x435e250) at /home/tomreyn/SCM/mandate/source/game/world/sim_interface.cpp:252
#8  0x00000000005ef94d in Glest::Gui::GameState::update (this=0x4027ef0) at /home/tomreyn/SCM/mandate/source/game/game/game.cpp:325
#9  0x000000000066262e in Glest::Main::Program::loop (this=this@entry=0x7fffc4908370) at /home/tomreyn/SCM/mandate/source/game/main/program.cpp:331
#10 0x000000000065f5e6 in Glest::Main::glestMain (argc=argc@entry=1, argv=argv@entry=0x7fffc49090c8) at /home/tomreyn/SCM/mandate/source/game/main/main.cpp:187
#11 0x000000000050a7bd in main (argc=1, argv=0x7fffc49090c8) at /home/tomreyn/SCM/mandate/source/game/main/main.cpp:220
gae-crash.txt has this:

Code: [Select]

Crash
Version: Advanced Engine 0.3.93
Built: Thu Jun 20 02:34:13 CEST 2013
Time: Sat Jun 22 12:05:11 2013
Description: SIGSEGV: address not mapped to object
Address: 0x200000942
Backtrace:
./build/source/game/glestadv(_ZN6Shared8Platform24PlatformExceptionHandler7handlerEiP9siginfo_tPv+0x1aa) [0x7aefca]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfbd0) [0x7f0c16112bd0]
./build/source/game/glestadv(_ZN5Glest3Gui16CharacterCreator20calculateCreatorCostEv+0x24) [0x5d3374]
./build/source/game/glestadv(_ZN5Glest3Gui16CharacterCreator13onButtonClickEPNS_7Widgets6WidgetE+0x36) [0x5d5616]
./build/source/game/glestadv(_ZN5Glest7Widgets6Button7mouseUpEN6Shared8Platform11MouseButtonENS2_4Math4Vec2IiEE+0x75) [0x755bd5]
./build/source/game/glestadv(_ZN5Glest7Widgets12WidgetWindow12eventMouseUpEiiN6Shared8Platform11MouseButtonE+0x45) [0x744085]
./build/source/game/glestadv(_ZN6Shared8Platform6Window11handleEventEv+0xdc) [0x7ae1bc]
./build/source/game/glestadv(_ZN5Glest4Main7Program4loopEv+0x224) [0x662644]
./build/source/game/glestadv(_ZN5Glest4Main9glestMainEiPPc+0x2b6) [0x65f5e6]
./build/source/game/glestadv(main+0x2d) [0x50a7bd]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f0c142f0ea5]
./build/source/game/glestadv() [0x50dba1]
Update:

The reason the game shuts down right after the start is that I had only a single (human) player defined, so I would immediately win. When there is also a CPU opponent, the game keeps running and the error only occurs when it shuts down.

A.I. looks quite broken (they will run past you, stand next to your buildings but not attack, attack your units but your units won't defend) but it works generally.

I'm also having selection issues (when I click on one building, several others nearby are selected, too), but this can be due to GLSelectBuf (a deprecated OpenGL feature) issues with my r300 MESA drivers on atibox (specs below).

[MoLAoS]

Can you report what it says in the error log in the same folder as crash? There might be some data missing or something.

Also try going to provision/factions/humans/units/defender/defender.xml and remove this section:

  <control type="inhuman">
    <personality type="defender"/>
  </control>

[tomreyn]

The XML modification you suggested works around / fixes it.

Without this, I keep crashing, and the following log files are created (I cleared out all logs before running this, so these all refer to the run which crashed):

Code: (~/.glestadv/gae-crash.txt) [Select]

Crash
Version: Advanced Engine 0.3.93
Built: Thu Jun 20 02:34:13 CEST 2013
Time: Sat Jun 22 17:38:38 2013
Description: SIGSEGV: address not mapped to object
Address: 0x13f800b40
Backtrace:
./build/source/game/glestadv(_ZN6Shared8Platform24PlatformExceptionHandler7handlerEiP9siginfo_tPv+0x1aa) [0x7aefca]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfbd0) [0x7f174d322bd0]
./build/source/game/glestadv(_ZN5Glest4Plan10GoalSystem8findLairEPNS_8Entities4UnitE+0x126) [0x52d266]
./build/source/game/glestadv(_ZN5Glest4Plan12MandateAISim10getTopGoalEPNS_8Entities4UnitESs+0xfc5) [0x53d605]
./build/source/game/glestadv(_ZN5Glest4Plan12MandateAISim13computeActionEPNS_8Entities4UnitESsSs+0x4d) [0x53dc4d]
./build/source/game/glestadv(_ZN5Glest4Plan12MandateAISim6updateEv+0x707) [0x53eeb7]
./build/source/game/glestadv(_ZN5Glest3Sim19SimulationInterface11updateWorldEv+0x383) [0x788ca3]
./build/source/game/glestadv(_ZN5Glest3Gui9GameState6updateEv+0xbd) [0x5ef94d]
./build/source/game/glestadv(_ZN5Glest4Main7Program4loopEv+0x20e) [0x66262e]
./build/source/game/glestadv(_ZN5Glest4Main9glestMainEiPPc+0x2b6) [0x65f5e6]
./build/source/game/glestadv(main+0x2d) [0x50a7bd]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f174b500ea5]
./build/source/game/glestadv() [0x50dba1]

=======================


Code: (~/.glestadv/glestadv-error.log) [Select]

Glest Advanced Engine: Error log file. 22-Jun-2013_17-38-29

Error loading widget.cfg : styles for UnitBar could not be loaded.
Error loading widget.cfg : styles for FactionDisplay could not be loaded.
Error loading widget.cfg : styles for ItemDisplay could not be loaded.
No files found: techs/provision/factions/humans/modifications/*.


Code: (~/.glestadv/glestadv-network.log) [Select]

Glest Advanced Engine: Network log file. 22-Jun-2013_17-38-29

5900000: Frame: 0 :: quitGame aborting game.
5900000: Frame: 0 :: constructGameWorld
5900000: Frame: 0 :: loadWorld
7110000: Frame: 0 :: initWorld
7150000: Frame: 0 :: SkillCycleTable built, numEntries = 72, messageSize = 1152 (@16)
7480000: Frame: 0 :: launchGame
9730000: Frame: 8 :: destroyGameWorld

glestadv-ai.log was also created but only contains a timestamp.

As the build timestamp indicates, my time zone is CEST, which is UTC +0200. All of the timestamps given are localized.

A core file was written by this OS' kernel, the looks of which seem familiar:

Code: [Select]

Program terminated with signal 11, Segmentation fault.
#0  0x00007f174d322aab in raise (sig=11) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:38
#0  0x00007f174d322aab in raise (sig=11) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:38
#1  0x00000000007aef1b in Shared::Platform::PlatformExceptionHandler::handler (signo=11, info=<optimized out>, context=<optimized out>) at /home/tomreyn/SCM/mandate/source/shared_lib/sources/platform/sdl/platform_util.cpp:282
#2  <signal handler called>
#3  Glest::Plan::GoalSystem::findLair (this=this@entry=0x7fffe0304de8, unit=unit@entry=0x4a1b6a0) at /home/tomreyn/SCM/mandate/source/game/ai_mandate/mandate_ai_personalities.cpp:1111
#4  0x000000000053d605 in Glest::Plan::MandateAISim::getTopGoal (this=this@entry=0x7fffe0304dc0, unit=unit@entry=0x4a1b6a0, personality="defender") at /home/tomreyn/SCM/mandate/source/game/ai_mandate/mandate_ai_sim.cpp:159
#5  0x000000000053dc4d in Glest::Plan::MandateAISim::computeAction (this=this@entry=0x7fffe0304dc0, unit=unit@entry=0x4a1b6a0, personality="defender", reason="compute") at /home/tomreyn/SCM/mandate/source/game/ai_mandate/mandate_ai_sim.cpp:275
#6  0x000000000053eeb7 in Glest::Plan::MandateAISim::update (this=this@entry=0x7fffe0304dc0) at /home/tomreyn/SCM/mandate/source/game/ai_mandate/mandate_ai_sim.cpp:383
#7  0x0000000000788ca3 in Glest::Sim::SimulationInterface::updateWorld (this=0x3917c80) at /home/tomreyn/SCM/mandate/source/game/world/sim_interface.cpp:252
#8  0x00000000005ef94d in Glest::Gui::GameState::update (this=0x38d97d0) at /home/tomreyn/SCM/mandate/source/game/game/game.cpp:325
#9  0x000000000066262e in Glest::Main::Program::loop (this=this@entry=0x7fffe0305010) at /home/tomreyn/SCM/mandate/source/game/main/program.cpp:331
#10 0x000000000065f5e6 in Glest::Main::glestMain (argc=argc@entry=1, argv=argv@entry=0x7fffe0305d68) at /home/tomreyn/SCM/mandate/source/game/main/main.cpp:187
#11 0x000000000050a7bd in main (argc=1, argv=0x7fffe0305d68) at /home/tomreyn/SCM/mandate/source/game/main/main.cpp:220
The only terminal output I get is this:

Code: [Select]

[/home/tomreyn/.glestadv] is in the search path.
[/home/tomreyn/SCM/mandate/data/game] is in the search path.
config-dir: /home/tomreyn/.glestadv
data-dir: /home/tomreyn/SCM/mandate/data/game

Init Window: 1 ms.
Init OpenGL: 55 ms.
Load WidgetConfig: 94 ms.
Renderer Load Config: 0 ms.
Renderer Init Resources: 351 ms.
Init Renderer: 367 ms.
Init Sound: 5 ms.
Renderer Init Menu: 0 ms.
Renderer Init Game: 314 ms.

[tomreyn]

In case it should help anyone, here's my build script:

Code: [Select]

#!/bin/bash
#
# Build Mandate on Linux

GAE_CONFIG_DIR="`readlink -f ~`/.mandate"

GAE_DATA_DIR="`readlink -f ~`/SCM/mandate/data/game"

# Debug or Release or RelWithDebInfo
CMAKE_BUILD_TYPE=RelWithDebInfo

echo '[ STAGE 1 ] Updating git repository...'
git pull $@

echo
echo "You're now at this commit:"
git log -1 --pretty=tformat:"%h (%H)"

echo
echo
echo '[ STAGE 2 ] Preparing build environment...'
NUMCORES=`lscpu -p | grep -cv '^#'`
if [ "$NUMCORES" = '' ]; then NUMCORES=1; fi
echo $NUMCORES CPU cores detected
mkdir -p build
cd build
LANG=en_US.utf-8 cmake -DGAE_CONFIG_DIR=$GAE_CONFIG_DIR -DGAE_DATA_DIR=$GAE_DATA_DIR -DCMAKE_BUILD_TYPE=$CMAKE_BUILD_TYPE ..

echo
echo
echo '[ STAGE 3 ] Building Mandate...'
LANG=en_US.UTF-8 make -j $NUMCORES
cd ../
echo
echo 'Run the game as: ./build/source/game/glestadv'

And here's the script I use for running / testing the builds:

Code: [Select]

#!/bin/bash
#
# Run Mandate in debugging mode

LC_ALL=C
glestcmd=./build/source/game/glestadv
#glestcmdenv="http_proxy='http://127.0.0.1:8080' vblank=0"
glestcmdenv=''
glestcmdprefix='stdbuf -o0'
glestcmdsuffix=$@
configdir=~/.glestadv
logdir=$configdir
stdouterrlog=$logdir/stdouterr.log
backtracelog=$logdir/backtrace.log

# Back up old logs and core dump just in case
for file in $logdir/*.log core
do
  if [ -f "$file" ]
  then
    mv -f $file $file.bak
  fi
done

ulimit -c unlimited
if [ "`ulimit -c`" != 'unlimited' ]
then
  echo 'Error: Failed to activate core dumps.' >&2
  exit 1
fi

export $glestcmdenv > /dev/null 2>&1
$glestcmdprefix $glestcmd $glestcmdsuffix 2>&1 | tee $stdouterrlog
#$glestcmdprefix $glestcmd $glestcmdsuffix 2>&1 | gzip > $stdouterrlog.gz

# Check for segfault
if [ -f $configdir/core ]
then
  echo ''
  echo 'Segmentation fault detected, analyzing...'
  echo ''
  #gdb -q -n -ex "thread apply all bt full" -batch $glestcmd core | tee $backtracelog
  gdb -q -n -ex "bt" -batch $glestcmd $configdir/core | tee $backtracelog
  echo ''
  echo "The above has been written to $backtracelog"
fi

[MoLAoS]

Okay, it looks like there is something it doesn't like in find lair, which is weird. The new AI must have some non-standard code that your computer doesn't like.

The XML workaround helped you because it took out the AI for the only active unit that used the new AI. However I suspect that faction will still crash if you played a longer game?

Did you see any tax collecters spawn? They spawn and load into the castle. Did they not crash? It would be really convenient if only the findLair function crashed.

[tomreyn]

In fact this time (having undone the workaround) I got a segfault just by starting the game, having the main menu load, and quitting:

Code: [Select]

Core was generated by `./build/source/game/glestadv'.
Program terminated with signal 11, Segmentation fault.
#0  0x00007f174d322aab in raise (sig=11) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:38
#0  0x00007f174d322aab in raise (sig=11) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:38
#1  0x00000000007aef1b in Shared::Platform::PlatformExceptionHandler::handler (signo=11, info=<optimized out>, context=<optimized out>) at /home/tomreyn/SCM/mandate/source/shared_lib/sources/platform/sdl/platform_util.cpp:282
#2  <signal handler called>
#3  Glest::Plan::GoalSystem::findLair (this=this@entry=0x7fffe0304de8, unit=unit@entry=0x4a1b6a0) at /home/tomreyn/SCM/mandate/source/game/ai_mandate/mandate_ai_personalities.cpp:1111
#4  0x000000000053d605 in Glest::Plan::MandateAISim::getTopGoal (this=this@entry=0x7fffe0304dc0, unit=unit@entry=0x4a1b6a0, personality="defender") at /home/tomreyn/SCM/mandate/source/game/ai_mandate/mandate_ai_sim.cpp:159
#5  0x000000000053dc4d in Glest::Plan::MandateAISim::computeAction (this=this@entry=0x7fffe0304dc0, unit=unit@entry=0x4a1b6a0, personality="defender", reason="compute") at /home/tomreyn/SCM/mandate/source/game/ai_mandate/mandate_ai_sim.cpp:275
#6  0x000000000053eeb7 in Glest::Plan::MandateAISim::update (this=this@entry=0x7fffe0304dc0) at /home/tomreyn/SCM/mandate/source/game/ai_mandate/mandate_ai_sim.cpp:383
#7  0x0000000000788ca3 in Glest::Sim::SimulationInterface::updateWorld (this=0x3917c80) at /home/tomreyn/SCM/mandate/source/game/world/sim_interface.cpp:252
#8  0x00000000005ef94d in Glest::Gui::GameState::update (this=0x38d97d0) at /home/tomreyn/SCM/mandate/source/game/game/game.cpp:325
#9  0x000000000066262e in Glest::Main::Program::loop (this=this@entry=0x7fffe0305010) at /home/tomreyn/SCM/mandate/source/game/main/program.cpp:331
#10 0x000000000065f5e6 in Glest::Main::glestMain (argc=argc@entry=1, argv=argv@entry=0x7fffe0305d68) at /home/tomreyn/SCM/mandate/source/game/main/main.cpp:187
#11 0x000000000050a7bd in main (argc=1, argv=0x7fffe0305d68) at /home/tomreyn/SCM/mandate/source/game/main/main.cpp:220
So I'm not sure this is really XML related, unless, well it may affect the background sequence on the main menu, too.

Code: [Select]

But it's true, also with the workaround in place, it's easy to make it crash (or rather freeze on the unloading / end-of-game screen, then segfault on Alt-F4) while playing a game:
Core was generated by `./build/source/game/glestadv'.
Program terminated with signal 11, Segmentation fault.
#0  0x00007f174d322aab in raise (sig=11) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:38
#0  0x00007f174d322aab in raise (sig=11) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:38
#1  0x00000000007aef1b in Shared::Platform::PlatformExceptionHandler::handler (signo=11, info=<optimized out>, context=<optimized out>) at /home/tomreyn/SCM/mandate/source/shared_lib/sources/platform/sdl/platform_util.cpp:282
#2  <signal handler called>
#3  Glest::Plan::GoalSystem::findLair (this=this@entry=0x7fffe0304de8, unit=unit@entry=0x4a1b6a0) at /home/tomreyn/SCM/mandate/source/game/ai_mandate/mandate_ai_personalities.cpp:1111
#4  0x000000000053d605 in Glest::Plan::MandateAISim::getTopGoal (this=this@entry=0x7fffe0304dc0, unit=unit@entry=0x4a1b6a0, personality="defender") at /home/tomreyn/SCM/mandate/source/game/ai_mandate/mandate_ai_sim.cpp:159
#5  0x000000000053dc4d in Glest::Plan::MandateAISim::computeAction (this=this@entry=0x7fffe0304dc0, unit=unit@entry=0x4a1b6a0, personality="defender", reason="compute") at /home/tomreyn/SCM/mandate/source/game/ai_mandate/mandate_ai_sim.cpp:275
#6  0x000000000053eeb7 in Glest::Plan::MandateAISim::update (this=this@entry=0x7fffe0304dc0) at /home/tomreyn/SCM/mandate/source/game/ai_mandate/mandate_ai_sim.cpp:383
#7  0x0000000000788ca3 in Glest::Sim::SimulationInterface::updateWorld (this=0x3917c80) at /home/tomreyn/SCM/mandate/source/game/world/sim_interface.cpp:252
#8  0x00000000005ef94d in Glest::Gui::GameState::update (this=0x38d97d0) at /home/tomreyn/SCM/mandate/source/game/game/game.cpp:325
#9  0x000000000066262e in Glest::Main::Program::loop (this=this@entry=0x7fffe0305010) at /home/tomreyn/SCM/mandate/source/game/main/program.cpp:331
#10 0x000000000065f5e6 in Glest::Main::glestMain (argc=argc@entry=1, argv=argv@entry=0x7fffe0305d68) at /home/tomreyn/SCM/mandate/source/game/main/main.cpp:187
#11 0x000000000050a7bd in main (argc=1, argv=0x7fffe0305d68) at /home/tomreyn/SCM/mandate/source/game/main/main.cpp:220
That's after I unloaded the tax collectors (I assume, they looked like Techs from the Tech faction) on the castle.

[tomreyn]

Hey Molaos,

since (assuming I got you right there) you're approaching a test release I just tried to build on Linux again but ran into an error (and plenty of warnings). The actual error is on line 2292.

Good luck with Mandate and the ADHD treatment.

[MoLAoS]

warning: override controls (override/final) only available with -std=c++11 or -std=gnu++11 [enabled by default]

These warnings appear to be based on some flag? And they are all in files I don't recall changing. I'll google it.

I pushed my latest files to Github. I'm not sure why a version that produced that error got sent. Should compile now.

[tomreyn]

Code: [Select]

warning: override controls (override/final) only available with -std=c++11 or -std=gnu++11 [enabled by default]
These warnings appear to be based on some flag? And they are all in files I don't recall changing. I'll google it.

I think that GNU CPP 4.7 (and probably newer) prints them. Compiling GAE bears them, too. (MegaGlest does not, so maybe talk to Softcoder if you can't figure it out by just searching the web.)

I pushed my latest files to Github. I'm not sure why a version that produced that error got sent. Should compile now.

Fixed, but there are more:

Code: [Select]

source/game/world/world.cpp: In member function 'void Glest::Sim::World::computeProduction()':
source/game/world/world.cpp:798:117: error: taking address of temporary [-fpermissive]
source/game/world/world.cpp:799:110: error: taking address of temporary [-fpermissive]

Full log

[MoLAoS]

Well, that doesn't seem like a problem to me, VC++ didn't care at all and the temporary is only used for two things and all of them are in the same scope so it shouldn't cause any trouble, I'll look at some simple ways to fix it but maybe you have a flag set that catches things which aren't really a problem?

Okay, it looks like I fixed it and I pushed that updated code through, although I can't be sure since I don't have a Linux compiler. According to my research I didn't actually have a problem but it is probably easier to just change the code than argue with any Linux users who try to compile the program. Basically its just a policy issue where some compilers are whinier than others just in case the programmer is stupid and doesn't know what they are doing.

[tomreyn]

I'm using the GNU C compiler v4.7.3 - using default flags.

I assume theses warnings...

Code: [Select]

override controls (override/final) only available with -std=c++11 or -std=gnu++11...are to make you aware that you are relying on a feature of the new (well ... somewhat - it's actually 2 years old now) C++11 standard - which compilers unaware of this standard will be unable to handle (so building on other platforms and operating systems which lack support for C++11 would fail, this may include OS X and supported Linux releases which do not use the very latest software, such as Debian Wheezy and Ubuntu 12.04 LTS). So, if I'm interpreting it correctly, and if you do not care about backward compatibility at this time this should be of no concern.

About temporary, there's more (or maybe the line numbers just changed) in the same file:

Code: [Select]

source/game/world/world.cpp: In member function void Glest::Sim::World::computeProduction():
source/game/world/world.cpp:797:140: error: taking address of temporary [-fpermissive]
source/game/world/world.cpp:798:133: error: taking address of temporary [-fpermissive]

Full log

From what I've heard, VC++ has a tradition on failing on standard compliance, and this is actually getting worse (in terms of compliance towards current C++ standards by the time of VC++ releases) lately.
Some of which Microsoft acknowledges themselves. So if it's used as the foundation of your primary development environment it may be good to ensure the code you produce will run on other systems, too (if that's intended). Amazon and Azure have free-for-a-year offers to host a Linux system "in the cloud", host1free.com offers similar but without expiry (but with more annoyances). If you feel like setting up an account with them I'll be happy to set a system up for you to compile Mandate on it. We could also manage it via MegaGlests' continuous integration (Jenkins). You could install VirtualBox or another virtualization software (VMWare, HyperV) and run Linux on your own computer below Windows including (sometimes sketchy) 3D acceleration.

[MoLAoS]

I went ahead and fixed the stupid pointer to temporary thing in a way that shouldn't bug your compiler.

As far as the feature of C++11, I am using the 2008 version of VC++ so I am not sure how that works. Did MS update it to have that feature?

I'll push the current version to the repo as soon as it finishes compiling.

[Yggdrasil]

I assume theses warnings...

Code: [Select]

override controls (override/final) only available with -std=c++11 or -std=gnu++11...are to make you aware that you are relying on a feature of the new (well ... somewhat - it's actually 2 years old now) C++11 standard - which compilers unaware of this standard will be unable to handle (so building on other platforms and operating systems which lack support for C++11 would fail, this may include OS X and supported Linux releases which do not use the very latest software, such as Debian Wheezy and Ubuntu 12.04 LTS). So, if I'm interpreting it correctly, and if you do not care about backward compatibility at this time this should be of no concern.

Not completely right. It's just telling you that you are using a reserved keyword from C++11 but haven't enabled C++11. The feature is not enabled.

In GAE it's just an empty macro when you haven't enabled C++11.
source/shared_lib/include/lang_features.h:357

Just ignore this warning or enable C++11.

[MoLAoS]

I went ahead commented out the code causing a problem, I'll need to redo a bunch of stuff later once I figure out how I want things to work precisely for BonusPowers.

Given Ygg's response and that, all the issues you posted about should be resolved.

[tomreyn]

Thanks for explaining, Ygg, and for commenting out problematic code for now, MoLAoS.

So I'll ignore the override controls warnings but I'm afraid I still run into the temporary error:

Code: [Select]

source/game/world/world.cpp:797:140: error: taking address of temporary [-fpermissive]
source/game/world/world.cpp:798:133: error: taking address of temporary [-fpermissive]
make[2]: *** [source/game/CMakeFiles/glestadv.dir/world/world.cpp.o] Error 1
make[1]: *** [source/game/CMakeFiles/glestadv.dir/all] Error 2
make: *** [all] Error 2

So basically that's unchanged?

Full log

[MoLAoS]

Thanks for explaining, Ygg, and for commenting out problematic code for now, MoLAoS.

So I'll ignore the override controls warnings but I'm afraid I still run into the temporary error:

Code: [Select]

source/game/world/world.cpp:797:140: error: taking address of temporary [-fpermissive]
source/game/world/world.cpp:798:133: error: taking address of temporary [-fpermissive]
make[2]: *** [source/game/CMakeFiles/glestadv.dir/world/world.cpp.o] Error 1
make[1]: *** [source/game/CMakeFiles/glestadv.dir/all] Error 2
make: *** [all] Error 2

So basically that's unchanged?

Full log

I actually forgot to push. Sorry. I just did it now.

[MoLAoS]

I apparently edited rather than quoted your post and this forum doesn't have history so I just deleted that and made this post.

I removed the Human faction from the repo so that should theoretically clear up all the errors.

Based on my test there should no longer be any errors opening the Character Creator, but it isn't completely polished and would probably be unusable for you just because certain parts aren't enabled and there isn't currently much data to work with for the RPG part anyways.