IRIX and Software

Hello all,

For the hell of it I tried to build the latest sources for GemRB ( http://en.wikipedia.org/wiki/GemRB ) on my Fuel (Planescape Torment was a kick ass game lol). Mipspro compiled almost straight away with very little tweaking - just some Makefile gorp.

That said when I run I get the following:

GemRB Core Version v0.2.9 Loading...
[Core]: Initializing Variables Dictionary...[OK]
[Config]: Trying to open GemRB.cfg
[OK]
[Core]: Starting Plugin Manager...
[PluginMgr]: Loading Plugins...
[PluginMgr]: Searching for plugins in: /usr/nekoware/gemrb/lib/gemrb/
[PluginMgr]: Loading: /usr/nekoware/gemrb/lib/gemrb/libGUIScript.so...[OK]
[PluginMgr]: Checking Plugin Version...[OK]
[PluginMgr]: Loading Exports for GUI Script Engine (Python)...[OK]
[PluginMgr]: Loading: /usr/nekoware/gemrb/lib/gemrb/libSDLVideo.so...[OK]
<snip>

all this is goodness until:

[KEYImporter]: Opening /usr/people/mejdrich/PST/CHITIN.KEY...[OK]
[KEYImporter]: Checking file type...[OK]
[KEYImporter]: Reading Resources...
[KEYImporter]: BIF Files Count: 1946222592 (Starting at 402653184 Bytes)
[KEYImporter]: RES Count: 1731133440 (Starting at 924975104 Bytes)
[Streams]: Invalid seek position: 402653184 (limit: 178649)
[Streams]: Invalid seek position: 402653184 (limit: 178649)
[Streams]: Invalid seek position: 796226418 (limit: 178649)
[Streams]: Invalid seek position: 402653196 (limit: 178649)
[Streams]: Invalid seek position: 796226418 (limit: 178649)
<goes on forever>
<snip>

Does this look familiar to anyone? I'm suspecting Endianness or iostream issues, etc, but thought I'd see if anyone had experienced anything similar...

Best regards,
Eric

I just spent a weekend on this but never tried the 0.2.x version you tried. I started with the latest 0.8.x and went down to 0.3.0 and then up to 0.7.0 and then 0.6.0.

Some errors in cmake or autogen.sh logs seem to be "Identifier va_list is undefined" .. since this is GNU-style code being built. I assume including stdarg.h may help this but im at a loss with using cmake and/or autogen.sh. The original poster used a much older version that probably didnt use these build tools.

versions newer than 0.6.0 seem to work with cmake (or autogen.sh but its not maintained anymore).

Newer versions cant seem to get past cmake.. ld32: FATAL I/O error (-lpthreads) .. and I know IRIX has some porting issues with pthreads but not sure how to solve that through cmake or autogen.sh.

Tried GCC 4.7 too but had different errors in cmake and/or autogen (or older versions with configure)

Can anyone help take a look at this software? It would really make my year (maybe my past decade) to be able to play Baldurs Gate, and the other Infinity engine games, on an SGI. SO much so.. maybe some monatary value can be placed on this

FYI, I did create a neko_cmake-2.8.6.tardist and uploaded to /incoming (should be moved to my dir sometime soon) as gemrb needed this version or later.

Links:
http://www.gemrb.org/wiki/doku.php?id=installation
http://www.gemrb.org/wiki/doku.php?id=i ... t_yourself

-Kevin

necron2600 wrote: Some errors in cmake or autogen.sh logs seem to be "Identifier va_list is undefined"

The problem there is that variable argument lists aren't implemented in MIPSPro C++. Depending on how much they're used in GemRB that can be either a slight pain in the ass or a complete show stopper, which for example it was with Dillo. What we should probably do is get the gnu va_list source code and compile it into a library and stick it in /usr/nekoware/lib and document in the wiki that you have to link against it to get va_lists to work in MIPSPro C++. I'd be willing to do that but I won't be able to get to it until the first week in January since my year-end todo list is at the total nightmare level this year.

I loved playing Baldur's Gate and other like it and I agree it would be fun to play on IRIX.

This is from /usr/include/internal/stdarg_core.h, redirected form /usr/include/CC/cstdarg
In other words, it is there, but it does need proper preprocessing. I'm using 7.4.4m and C-style headers are still not properly supported which necessitates me to use odd options in CXXFLAGS.
I do get somewhere in gemrb 0.8.3.1 : i reach 15% with an error in:
which is strange since wholeparty is a std::vector<Injured> template and std::vector does have the .at() class function. So this needs weeding through code.

For peeps wondering what setenv i used: and two hacks in neko_cmake modules in /usr/nekoware/share/cmake-2.6/Modules
Since if it finds sproc, it ignores pthreads alltogether which in modern day code is certainly not what you want.

So it definitely needs some work, we're not there yet.

dexter1 wrote: ...which is strange since wholeparty is a std::vector<Injured> template and std::vector does have the .at() class function. So this needs weeding through code.

Sometimes you can fix that by moving the #include <vector> line to a different place in the source code file, for example try moving it to be the first #include directive in the file. For some reason the preprocessor gets confused if it's already read in a bunch of headers and the compiler starts calling non-member errors on things that definitely are members...

Yeah indeed, Thanks for that tip! By adding (or moving) a C++ header above the C-headers (<cmath>,<cstring>) most undefined type-errors disappear. I found the same fix on an old thread.

This fix also enables me dropping the -LANG:libc_in_namespace_std option in CXXFLAGS since it broke std::vector::at() : it turns out that std::vector does have ::at() as per c++03 standard which MIPSPro supports. Yay.

However i got this:


I initially thought this was the same error as the one previously, but unfortunately the error is about missing ::at() in std::map. Even worse, this is added in the c++11 standard MIPSPro CC compiler version 7.4.4m doesn't support c++11 so that's end of the line.

But before i start crying and drag this code through gcc 4.6 or 4.7, it is however easily fixed in MIPSPro, due to the nature of that specific function:


by doing this:


Basically i used a map::const_iterator for the fonts class, so i can find the font pointer via the iterator instead of ::at()
There are other solutions on the internet by overloading the ::at() function for std::map and build a small function using one loop, ::find() and an exception handler.

Well, let's hope i do not encounter more c++11 specific language syntax...

That's top notch investigative coding dexter, nice work!

Hi Dexter... any updates/status on your efforts for GemRB? Just wondering if it has gone anywhere or not.
Thanks

Sorry for not replying sooner, necron2600. I had another look last week and the problems at 82% was in GUIScript.cpp which basically boils down to include header hell. The solution is to compile the offending code with the -E option and sift through the output. That took a bit of time...

I did some more work on the code today and i patched it up to the point that gemrb and its plugins compile. The SDL plugin gets stuck with gettimeofday() so i have to revisit the #include <sys/time.h> fix i did for that.

Here is the patch file for gemrb-0.8.3.1
It's probably my ugliest patch file i have ever made sofar. Feel free to mock it

I'll get around to building something useful in the coming days. I'm still not sure if there are endian issues. Also no idea how to test this. Pointers are welcome.

hey guys, gemrb dev here.

I've amended and merge about half of Dexter's patch and this is what remains:
http://sprunge.us/TPJi?diff

So four things:
1. The mentioned time hacks, which seem more like something to be changed in your libc?
2. Unfinished changes I don't fully understand, since I have no way of testing:
- why the token change?
- why are only some str(n)icmp calls problematic and why? We define them to be the same everywhere but on windows.
- what tripped you up in Holder.h?

It'd be great if someone took git HEAD for a spin and report any other problems. For a trivial test just run with -c gemrb/tests/minimal/test.cfg . There's also one that pops up a window and loads a game, but we apparently don't ship a config (set GameType=demo): demo/data .

Btw, the code should already be endian-safe.

lynx wrote: hey guys, gemrb dev here.

I've amended and merge about half of Dexter's patch and this is what remains:
http://sprunge.us/TPJi?diff

So four things:
1. The mentioned time hacks, which seem more like something to be changed in your libc?
2. Unfinished changes I don't fully understand, since I have no way of testing:
- why the token change?
- why are only some str(n)icmp calls problematic and why? We define them to be the same everywhere but on windows.
- what tripped you up in Holder.h?

It'd be great if someone took git HEAD for a spin and report any other problems. For a trivial test just run with -c gemrb/tests/minimal/test.cfg . There's also one that pops up a window and loads a game, but we apparently don't ship a config (set GameType=demo): demo/data .

Btw, the code should already be endian-safe.

Hello Lynx,

Thanks for coming here and looking into my patch. I'm currently installing and preparing my gemRB environment on a spare O2, since i have decided to rebuild part of our Nekoware distribution on my current workstations at home. My former gemRB dev machine, a O200 at work, is down for the moment so it will take me a bit of time to set everything up and start again.

I'll be back with some more info as soon as i have a compile in progress.

Ok, no rush, we have some major stuff to finish before it's worthy of a new release (mostly random bugfixes so far).

necron: the same applies to you. If you had to massage it in any way to get it to run on Solaris, show me the diff.

Too bad you guys didn't talk to us sooner.

Lynx,
Solaris 10 compiled without any mods.. I was actually surprised at how smoothly the compile went. I had a full Solaris10/sparc OpenCSW stack ( www.opencsw.org ) installed and compiled GemRB with gcc.

I had posted the compiled binary for solaris 10 (sparc) here on nekochan.net:
viewtopic.php?f=17&t=16730822&p=7391249&hilit=gemrb&sid=bf95f103daf4682fc1b44e199499c336#p7391249

It plays well (not slow at all) on a SUN Ultra 2 workstation from the 1990's with Solaris 10. I also had it playing through a thin-client SUN Ray with its 'host' being a mid 2000's SPARC server.

Just 1 minor issues on Solaris (SPARC):
Once in awhile when roaming around, gemrb will just hang. If I save often, its easy enough to restart the game and load. No errors or signs of why it hangs shows anywhere. And it is randomly anywhere on a map. Could be triggered by sounds, footsteps, an enemy, etc..? Its not too bad, maybe 2 hangs in one map while exploring, etc..

Thanks again!

Great, thanks.

Nobody reported any hanging, so it could be platform specific. Or perhaps a memory problem. No matter, it's a pretty obvious problem that should crop up during pre-release testing if it is generic.

oh, one thing slipped through the cracks. In one file you had to forward declare strlcpy and include strings.h manually. Are all string.h/cstring includes supposed to be stringS.h on irix? Cause maybe the ifdefing can then be centralised, so it doesn't need to pollute that many files.

I was able to get a succesful compile (but not execute) by going to the dark side with GCC (versus SGI MIPS Pro compiler). Since I had this working with Solaris 10/sparc and GCC I figure it would be easier with GCC vs MIPSPro.. at least initially. I did need a bunch of source code adjustments but nothing too serious.

However, gemrb fails to run:

gemrb
417106:gemrb: rld: Error: unresolvable symbol in /usr/local/lib/libgemrb_core.so.1: _ZN5GemRB15GemMarkupParser30ParseMarkupStringIntoContainerERKSbIwSt11char_traitsIwESaIwEERNS_13TextContainerE
417106:gemrb: rld: Error: unresolvable symbol in /usr/local/lib/libgemrb_core.so.1: _ZN8RNG_SFMT11getInstanceEv
417106:gemrb: rld: Error: unresolvable symbol in /usr/local/lib/libgemrb_core.so.1: _ZN5GemRB15GemMarkupParser5ResetEv
417106:gemrb: rld: Error: unresolvable symbol in /usr/local/lib/libgemrb_core.so.1: _ZN5GemRB15GemMarkupParser15ResetAttributesEPKNS_4FontEPNS_7PaletteES3_S5_
417106:gemrb: rld: Error: unresolvable symbol in /usr/local/lib/libgemrb_core.so.1: _ZN5GemRB15GemMarkupParserC1EPKNS_4FontEPNS_7PaletteES3_S5_
417106:gemrb: rld: Error: unresolvable symbol in /usr/local/lib/libgemrb_core.so.1: _ZN5GemRB15GemMarkupParserC1Ev
417106:gemrb: rld: Error: unresolvable symbol in /usr/local/lib/libgemrb_core.so.1: _ZN8RNG_SFMT4randEii
417106:gemrb: rld: Error: unresolvable symbol in /usr/local/lib/libgemrb_core.so.1: _ZN5GemRB9VEFObject15GetSingleObjectEv
417106:gemrb: rld: Error: unresolvable symbol in /usr/local/lib/libgemrb_core.so.1: _ZN5GemRB9VEFObject4DrawERKNS_6RegionERNS_5PointERKNS_5ColorEPNS_3MapEiii
417106:gemrb: rld: Error: unresolvable symbol in /usr/local/lib/libgemrb_core.so.1: _ZN5GemRB9VEFObjectC1EPNS_17ScriptedAnimationE
417106:gemrb: rld: Error: unresolvable symbol in /usr/local/lib/libgemrb_core.so.1: _ZN5GemRB9VEFObject7Load2DAEPKc
417106:gemrb: rld: Error: unresolvable symbol in /usr/local/lib/libgemrb_core.so.1: _ZN5GemRB9VEFObjectC1Ev
417106:gemrb: rld: Error: unresolvable symbol in /usr/local/lib/libgemrb_core.so.1: _ZN5GemRB9VEFObjectD1Ev
417106:gemrb: rld: Error: unresolvable symbol in /usr/local/lib/libgemrb_core.so.1: _ZN5GemRB9VEFObject7LoadVEFEPNS_10DataStreamE
417106:gemrb: rld: Fatal Error: this executable has unresolvable symbols

Its possible I need to recompile cleanly.. as i made changes mid-way in the compiling.. may have objects built but later not not used,etc.. This could also open up a can of worms on my end and make it not able to compile.

Dexter.. regarding your time issues.
This may be related to your issue with MIPSPro.. then again it may not be:
I got this error during compiling:
In file included from /usr/nekoware/include/python2.7/pyport.h:325:0,
from /usr/nekoware/include/python2.7/Python.h:58,
from GUIScript.h:31,
from GUIScript.cpp:24:
/usr/include/sys/time.h: In function 'int select(int, fd_set*, fd_set*, fd_set*, timeval*)':
/usr/include/sys/time.h:191:26: error: 'int select(int, fd_set*, fd_set*, fd_set*, timeval*)' was declared 'extern' and later 'static' [-fpermissive]

Googling (dont need coding skills anymore when you can google! I found:
http://pysvn.stage.tigris.org/ds/getDSM ... =text/html

By putting an #include <sys/time.h> 'before' Python.h cleared my time related issues.. but they were with GCC.

I'll let a fresh recompile run overnight and see how that goes (GCC again).

Thanks for the info. Currently my office does a pretty good job of murdering me and what's left of my spare time is dumped into holiday celebrations.
What Cmake did you use for the gemRB source?

cmake 2.8.6
I have a tardist of it here:
http://www.nekochan.net/downloads/index ... ecron2600/

So I was able to get it compiled again.. no errors (but I did remove -Werror compile option that would turn warnings to errors.. maybe im missing something by doing that)

Among several more unresolvable symbols.. the errors when running gemrb are:
[octane]:/usr/local/lib $ gemrb
444271:gemrb: rld: Error: unresolvable symbol in /usr/local/lib/libgemrb_core.so.1: _ZN5GemRB15GemMarkupParser30ParseMarkupStringIntoContainerERKSbIwSt11char_traitsIwESaIwEERNS_13TextContainerE

Well.. where is this symbol?
I used nm to find it in itself:
[octane]:/usr/local/lib $ nm -gC libgemrb_core.so.1 | grep _ZN5GemRB15GemMarkup
Parser30ParseMarkupStringIntoContainerERKSbIwSt11char_traitsIwESaIwEERNS_13Text
ContainerE
[5637] | 0| 0|OBJT |GLOB |DEFAULT |UNDEF |_ZN5GemRB15GemMarkupParser30ParseMarkupStringIntoContainerERKSbIwSt11char_traitsIwESaIwEERNS_13TextContainerE

seems all the symbols being complained about have a value of '0''
some type of Markup Parser, Font stuff, and a VEFObject
hmm. regarding fonts.. I do remember fudging the code a bit:

During a compile, I had received:
## ERROR
gmake[3]: *** No rule to make target `Font.cpp', needed by `Font.lo'. Stop.
gmake[3]: Leaving directory `/tmp/gemrb/gemrb/gemrb/core'

I found no Font.cpp anywhere.. except from a core/GUI/TextSystem/* directory.
To make the compile work, I just copied from core/GUI/TextSystem/* to gemrb/core/.
Maybe that is one of the sources of my problem.
I did note that in older gemrb versions Font.cpp exists in core/.. but not in newer versions. (I am using a checkout of HEAD right now). I would point a finger to the code, but this compiled cleanly on a Solaris box. Ill try to compare what happened on the Solaris box.

What's your procedure? I get a feeling you're somehow mixing the cmake build with the old autotools one, since the unmaintained gemrb/core/Makefile.am is the only thing referencing core/Font.cpp.