Linux i686 and x86-64

Author

122

January 23, 2009 06:37 AM

Hi, I'm trying to get Angelscript running on Linux, both on 32bit and 64bit, but without much luck at the moment. I'm currently running the latest SVN version as of yesterday, but I've tried before with the stable version with unsuccessful results. There are some issues with compiling on both platforms, firstly the in atomic.cpp. Looks like you've used a kernel header for your asCAtomic class which is a bit of a no-no according to the kernel developers, these functions/headers are only really meant to be used inside the kernel. I've changed it to use gcc built in atomic functions which seems to work o.k. for the few tests that do pass at the moment. See below for the changes.


#include <asm/atomic.h>
BEGIN_AS_NAMESPACE
asDWORD asCAtomic::atomicInc()
{
    return atomic_inc_and_test(value);
}
asDWORD asCAtomic::atomicDec()
{
    return atomic_dec_and_test(value);
}


#include <asm/atomic.h>
asDWORD asCAtomic::atomicInc()
{
    return __sync_fetch_and_add(&value, 1);
}
asDWORD asCAtomic::atomicDec()
{
    return __sync_fetch_and_sub(&value, 1);
}

I'm using test_feature to check Angelscript performs as expected, but I've had to change a few of the tests in order to get it to compile. The vector3 tests require scriptmath3d, but scriptmath3d needs new.h which I'm guessing is part of the MS CRT library? So for the moment I've just #ifndef __LINUX__ these tests out, perhaps once the rest of the code is working I'll look at trying to get this built as well. On 64bit I've also had to #ifdef out a few of the tests in test_registertype due to them using asCALL_CDECL. Anyway my current fail on 64bit is in test_stringscript testing script3, this seems to stem from the fact in asCContext::CallGeneric currentObject is NULL, so further on in scriptstring.cpp CScriptString::operator= is getting passed NULL for other. I'll do some more digging and see if I can work out the exact cause of this, but perhaps you might be able to point me in the right direction?

WitchLord

4,860

January 23, 2009 10:25 AM

Ah, thanks for the tip. I'm not experienced on Linux programming, so I was not aware of this. I'll change the code accordingly.

As for the scriptmath3d.cpp, I believe you can use #include <new> instead of #include <new.h>.

It's been a while since I tested the library with AS_MAX_PORTABILITY. A lot of the tests in test_feature have not been prepared for this. You can just skip these, and I'll add the proper check for portability mode in the SVN.

The fact that test_scriptstring fails surprises me. But then again, I don't have any 64bit machine to test AngelScript on. I can't say where the bug is, but if you set a break pointer in the constructor for the asCGeneric class in the library and check for moments where the currentObject is set incorrectly you may be able determine where the error is. Probably it has to do with a type cast from int to pointer, or something like that.

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

WitchLord

4,860

January 23, 2009 06:21 PM

I've checked in some changes that ought to clear away most of the problems you were having while trying to get AS working on Linux 64bit.

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

_Vicious_

330

February 07, 2009 07:51 AM

hello!
Not sure if it's a bug or not, but the current linux version of as_atomic.cpp seems to be missing a __sync_fetch_and_add call:

asDWORD asCAtomic::atomicInc()
{
return (&value, 1);
}

Also, the builtin gcc __sync_* calls are only available in gcc versions >= 4.1, compiling AS on systems with more dated gcc is currently impossible.

Thanks!

_Vicious_

330

February 07, 2009 08:19 AM

Here's a version of the AS_LINUX block of as_atomic.cpp that works for all systems (I've also patched the atomic_*_and_test calls):

#elif defined(AS_LINUX)#if ( ( (__GNUC__ == 4) && (__GNUC_MINOR__ >= 1) || __GNUC__ > 4) )//// atomic_inc_and_test() and atomic_dec_and_test() from asm/atomic.h is not meant // to be used outside the Linux kernel. Instead we should use the GNUC provided // __sync_fetch_and_add() and __sync_fetch_and_sub() functions.//// Reference: http://golubenco.org/blog/atomic-operations/// asDWORD asCAtomic::atomicInc(){	return __sync_fetch_and_add(&value, 1);}asDWORD asCAtomic::atomicDec(){	return __sync_fetch_and_sub(&value, 1);}#elseEND_AS_NAMESPACE#include <asm/atomic.h>BEGIN_AS_NAMESPACEasDWORD asCAtomic::atomicInc(){	return atomic_inc_and_test((atomic_t *)&value);}asDWORD asCAtomic::atomicDec(){	return atomic_dec_and_test((atomic_t *)&value);}#endif

_Vicious_

330

February 07, 2009 08:46 AM

Or, alternatively, in as_config.h

#if defined(AS_LINUX) && !( ( (__GNUC__ == 4) && (__GNUC_MINOR__ >= 1) || __GNUC__ > 4) )	#define AS_NO_THREADS#endif

which is probably a safer solution

WitchLord

4,860

February 07, 2009 10:14 AM

Thanks _Vicious_. I've checked in the changes you proposed for as_atomic.cpp.

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

_Vicious_

330

February 07, 2009 11:09 AM

The problem is that with gcc 3.3.4 the program crashed very soon after AS initialization, disabling multithreading fixed that, hence the second patch.

_Vicious_

330

February 07, 2009 04:52 PM

Sorry for sidetracking the thread a bit, I'm testing our implementation of AS scripts on a x64 linux machine and I can't get it to work so far. The program crashes (SIGSEGV) in a refcount function, here's the backtrace

0x00007ff73c125f88 in objectString_Addref (obj=0x128f6600128f660) at game/g_ascript.c:859859     static void objectString_Addref( asstring_t *obj ) { obj->asRefCount++; }(gdb) backtrace#0  0x00007ff73c125f88 in objectString_Addref (obj=0x128f6600128f660) at game/g_ascript.c:859#1  0x00007ff73c125fb4 in objectString_asGeneric_Addref (gen=0x7fff478d93b0) at game/g_ascript.c:863#2  0x00007ff73e236629 in asCScriptEngine::CallObjectMethod (this=0x12356b0, obj=0x128f6600128f660, i=0x1241880, s=0x12418e0)    at ../../source/as_scriptengine.cpp:2668#3  0x00007ff73e236766 in asCScriptEngine::CallObjectMethod (this=0x12356b0, obj=0x128f6600128f660, func=41) at ../../source/as_scriptengine.cpp:2658#4  0x00007ff73e28f5e4 in asCContext::ExecuteNext (this=0x1297d00) at ../../source/as_context.cpp:2307#5  0x00007ff73e293076 in asCContext::Execute (this=0x1297d00) at ../../source/as_context.cpp:1096#6  0x00007ff73e29ee78 in asCModule::CallInit (this=0x1268450) at ../../source/as_module.cpp:217#7  0x00007ff73e29f14b in asCModule::Build (this=0x1268450) at ../../source/as_module.cpp:168#8  0x00007ff73e22e6b8 in qasBuildModule (engineHandle=0, module=0x7ff73c1ab10f "gametypes") at angelwrap/qas_angelwrap.cpp:629#9  0x000000000043a11b in ?? ()(gdb)

Note the the obj pointer address seems to be valid.

gargltk

125

February 07, 2009 07:58 PM

It looks to be valid but it is not. Look closely at the value:

0x128f6600128f660

That is in fact the correct address - '0x128f660' - with itself added to the end - '0128f660'. I've encountered and reported this problem here. I'm still hacking away at the native calling conventions for x86_64/gcc (still haven't quite gotten virtuals to work properly) but once I'm done with that I'll have a look. WitchLord has also promised to look into it.

Linux i686 and x86-64

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Linux i686 and x86-64

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines