Exult Forum

First of all, after some pause from U7, I'm glad to return here and see Exult's still alive.

But on topic:
I'm trying to build the latest snapshot, configure sees the cross compiler correctly (arm-linux-gnueabihf-gcc from Linaro) and everything seems to go fine until (I got PL locale, so I translated the error messages, I don't know how they look like originally):

make[2]: Entering directory `/home/alagner/exult/data'
../tools/expack -i ./flx.in
../tools/expack: ../tools/expack: can not run binary file
make[2]: *** [exult.flx] Error 126
make[2]: Leaving director `/home/alagner/exult/data'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/alagner/exult'
make: *** [all] Error 2

Not being able to run cross-compiled file seems pretty much ok, but why bother trying it?
Any advice on that topic, please?

If it matters:
my uname -a states the following
Linux linux-gz62 3.1.10-1.16-default #1 SMP Wed Jun 27 05:21:40 UTC 2012 (d016078) i686 athlon i386 GNU/Linux

Generally - Linux runnig on a virtual box.

and gcc version is:
gcc version 4.7.2 20120731 (prerelease) (crosstool-NG linaro-1.13.1+bzr2458 - Linaro GCC 2012.08)


Thanks in advance.

Pass --disable-data and --disable--tools to configure, I think.
Normally we need to build and run expack to create flx files with Exult's data files in them. Unfortunately this is not cross compile proof. You will need to either compile exult for your machine to get those or grab them off a recent snapshot from our download page.

If you come up with a way to make this work for cross compilers it would bevery useful

And please let us know how well Exult works
I recently got a RPi myself but only use it in headless mode for server stuff...

One more thing - what's the problem with vorbis/codec.h not existing? I tried passing vorbis paths to configure manually, but the only thing I've got is:

./../audio/Midi.h:25:26: fatal error: vorbis/codec.h: No such file or directory
compilation terminated.
make[2]: *** [bggame.lo] Error 1
make[2]: Leaving directory`/home/alagner/exult/gamemgr'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/alagner/exult'
make: *** [all] Error 2

Latest snapshot of course.

Hmm, did you install both vorbis and ogg into the cross compile prefix? What did you pass on to configure and where are the ogg/vorbis headers?
Also you just might have to edit the main and midi makefile to point to the ogg/vorbis stuff - as last resort

Tried both of it. I have even compiled vorbis and ogg from source and put them in my home dir (~/vorbis and ~/ogg respectively). Paths in makefiles seem ok

And params for configure were --with-vorbis=/home/alagner/vorbis
--with-ogg=/home/alagner/ogg

And in those you have the subfolders lib and include?

Exactly.

If it compiles normally for you (with the ogg and vorbis configure options), compare the makefile with the cross conpilation makefile.

OK, I'm gonna drop a line here when I find sth out. Wish me luck

Ok, so the news is:
tried to cross compile yesterdays snapshot, but for win32, i686-w64-mingw32-gcc complains about WinMain16 or sth like that while trying to link -lmingw.
W/O this switch, it complains about SDL_main.
Googling it led me to SDL page, where it states, that there is sth wrong with main function overloading, I you guys could give me a hint it would be great.

It was done just for testing whether the cross compiler works (should work, as I compile OpenOCD pretty often, and judging by the error message it really does).

I can't remember what the error was when compiling for raspi, but the point is - tomorrow I'm gonna copy raspis /usr/lib and /usr/incled to my cross lib and inc dirs to eliminate possible wrong build of SDL/ogg/anything else.
Any other ideas?

Native Linux compilation of course works perfectly fine.

And one more thing:
arm-linux-gnueabihf-gcc --print-search-dirs

outputs nothing, but I pass LDFLAGS=-L/usr/arm-linux-gnueabihf/lib and CPPFLAGS=-I/usr/arm-linux-gnueabihf/include to configure everytime. Tried also passing it to make.

ok, I can reproduce this and it is indeed a problem on our side when you don't have CPPFLAGS, CFLAGS, CXFLAGS, LDFLAGS set (or the OGG/VORBIS stuff in there).
Some makefile.am files had the $(VORBIS_CFLAGS) $(OGG_CFLAGS) missing.
I'm fixing this right now...

Next snapshot should have it or you grab it straight from SVN.