The collected works of lynx

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.

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.

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.

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.

Ah well, if you go that route, you'll have to fix the Makefiles first. What errors did you get the cmake way?

I think I know the cmake problem — Travis CI or Appveyor hit something similar or identical. Checking ... yeah, odd cmake version, this was the fix:
sed -i 's,\(FIND_PACKAGE.*\) MODULE,\1,' CMakeLists.txt # just removing the MODULE parameter

since I guess your sed doesn't have -i, use redirection or edit the file manually (just three hits).

I'll go play with moved time.h and some of the rest.

oh, you can pass -DDISABLE_WERROR=1 to ...

does IRIX have stricmp instead of strcasecmp?

... yeah, cmake 2.8.8 introduced MODULE. If you refetch git HEAD (git pull), you should be able to run cmake without errors without mods.

ok, so it's just a case of missing includes then.

ldexpf is C99 and maybe a glibc extension. BIKPlayer is only needed for iwd2 movies though. I'll just disable the whole plugin build if the function isn't available — too lazy to find a reliable standalone implementation (could be tricky, since floats are involved).

What was the problem with openal? You can disable it through ccmake or passing a flag.

We use strcasecmp everywhere but on windows (stricmp is its alias).

The GUIScript plugin is essential. Can you post your current "git diff" the next time?

I've pushed some changes, so you don't have to hack BIKPlayer away anymore. Or CMakeLists.txt for the module stuff.

Are the FP constants really needed in both headers?

stricmp is just a macro, so WTF do you need to change the uses?
#ifndef WIN32
# define stricmp strcasecmp
# define strnicmp strncasecmp
#endif

you can run git checkout dir/asd/asd/file to reset your copy of a file to what is upstream. Do that for CMakeLists or you'll get conflicts when updating. So something like
git checkout CMakeLists.txt
git checkout gemrb/plugins/BIKPlayer/*
git stash
git pull
git stash pop

if you run "git log", what is the last commit? You definitely shouldn't need all the hacks from before.

If you don't want to use git, use the tarball from this url, so you'll have the latest changes:
https://github.com/gemrb/gemrb/archive/master.zip

I've committed a modified version of your diff — it's safe only for the cases from the first ifdef. Thanks!

Cool! The goal is to have it compile out of the box, so a diff vs HEAD would be great.

Heyya. HEAD now has all your work. Please play with that when debugging, 0.8.4 is history. The crashes happen when trying to display text in the chat box. Don't mind ResourceManager, since we do selective logging.

The demo is a mess, ignore that for now.

Are you two building with sdl1 or 2?

I'm subscribed to this thread, no worries. Your stack is scary and I can't test it myself, so my options are limited. What are values of things in the line where it breaks in GemRB::Font::RenderText? Did something overflow etc.

Those are the function arguments, not where it crashed (and mostly opaque pointers). If I understood correctly, the last line in GemRB was:
line = string.substr(stringPos, eolpos - stringPos);
So is string still sane? What's its length? Are stringPos and eolpos within limits ...

the function is ready for canvas to be null — if that were the main problem, it'd crash more cleanly.