ToME: the Tales of Maj'Eyal

Posted: **Sun Jul 31, 2011 1:43 am**

Hello. I have two versions of Beta31 installed on my Dual-Boot (Linux / Windows XP) laptop:

The Linux 32 binary version, and
the source code version,

both installed into separate folders.

uname -a :
Linux Aphrodite 2.6.32-21-generic #33 SMP Tue Apr 20 23:50:36 CEST 2010 i686 GNU/Linux

The binary Linux 32 version does after all run, so that I must conclude that my system meets the runtime dependencies. But if I try to build the source folder with

premake4 gmake
make

this is the error message I get, and I suspect I'm getting it right on the first build target:

Code: Select all

(...)
luajit2/src/lj_opt_fold.c                                                       
lj_opt_fold.c                                                                   
lj_dispatch.c                                                                   
lj_record.c                                                                     
lib_init.c
lj_crecord.c
lj_alloc.c
lib_math.c
lj_opt_loop.c
lj_char.c
lj_vmevent.c
lj_clib.c
lib_package.c
lj_parse.c
lj_func.c
lj_opt_narrow.c
lib_table.c
lj_gdbjit.c
lj_ccall.c
lj_meta.c
lj_cdata.c
lj_cconv.c
lj_bc.c
lj_gc.c
lj_ir.c
lj_bcwrite.c
lj_bcread.c
lj_opt_split.c
lj_snap.c
lj_debug.c
lj_ctype.c
lj_cparse.c
../src/luajit2/src/lj_cparse.c: In function ‘cp_get_bs’:
../src/luajit2/src/lj_cparse.c:59: sorry, unimplemented: inlining failed in call to ‘cp_get’: function body not available
../src/luajit2/src/lj_cparse.c:76: sorry, unimplemented: called from here
make[1]: *** [../obj/Debug/luajit2/lj_cparse.o] Error 1
make: *** [luajit2] Error 2

Now some of you might think that there's a deep-seated problem here, but I have a simplistic idea of what might be going wrong, based on feedback which I've already gotten on this forum. Somebody told me, that this project ships with its own Lua compiler as part of the source tree, and that this Lua compiler possesses LuaJIT.

What might be happening, is that the make process might be invoking the Lua compiler which is already installed on my laptop, instead of invoking the 'luac' which ships as part of the source tree. Because, I do have Lua 5.1 installed.

One problem with Debian / Lenny Lua from the package manager, is that LuaJIT does not come as an available package.

But then again, somebody on this forum might be able to spot some other cause for this problem.
I could be satisfied that the binary Linux 32 folder essentially runs, but in reality I'm more of a perfectionist than that. And I'm wondering whether I'd ever become capable of getting the t-engine to compile under Linux...

Your input is appreciated, and within reason I'm willing to perform tests and experiments on my source folder.

Dirk

Posted: **Sun Jul 31, 2011 2:20 am**

What I've done is to open the file within the source tree named 'build/options.lua' .
I changed the last line to

Code: Select all

_OPTIONS.lua = _OPTIONS.lua or "default"

And now the source code compiles properly!
Mind you, without the JIT compiler, it would probably run like molasses. But the success of this fix seems to confirm my earlier theory.

Dirk

Posted: **Sun Jul 31, 2011 10:37 am**

Without alterring the build file you can just run

Code: Select all

premake -lua=default gmake

But the error is because you have an old GCC, just use the precompiled one

Posted: **Mon Aug 01, 2011 2:42 am**

Thanks for the pointer on using premake4.

I am a bit skeptical about your explanation for my earlier compile problem though. And this is the reason:

Code: Select all

dirk@Aphrodite:~$ which premake4
/usr/local/bin/premake4

Since my command was 'premake4 gmake' and not './premake4 gmake' , the version of premake4 was used which I custom-compiled and installed to my root file system. It generated the Makefiles. And then I don't see why those would use any other 'luac' compiler than the one which is also installed to my root file system. Which does not have JIT.

Code: Select all

dirk@Aphrodite:~$ which luac
/usr/bin/luac

Now, as long as I can't get my screensaver bug solved in the source code, I have every reason to do as you say, and to use the precompiled version, simply because that version is in fact JIT-compiled.

[And yes, I understand that the "t-engine" executable acts as the true Lua interpreter in this case, for which purpose it was compiled against liblua statically by yourselves.]

Dirk

[Edit] I needed to look for ways to test my own skepticism. And so what I just simply tried, was

premake4 --lua=jitx86 gmake
make

I figured that if --lua=default worked, but --lua=jit2 did not, this was still too ambiguous.
What I discovered was that the option --lua=jitx86 works !!

So now I've learned four things from this experiment:

1) I am in fact able to compile t-engine with some form of JIT,

2) It does after all seem likely, that there's a problem with my (presumably outdated) GCC,

3) 'premake4' does not seem to include any directories, which are not explicitly listed in its script, not even the internal lua directories, and

4) I should be much less sure about my own default assumptions these days.

My GCC version is 4.3.2-1.1 .

ToME: the Tales of Maj'Eyal

[Solved] (Beta 31) Build problem under Debian / Lenny.

[Solved] (Beta 31) Build problem under Debian / Lenny.

Re: [Solved] (Beta 31) Build problem under Debian / Lenny.

Re: [Solved] (Beta 31) Build problem under Debian / Lenny.

Re: [Solved] (Beta 31) Build problem under Debian / Lenny.