Hi I'm attempting to use AngelScript 2.1.0 on linux. At first it wouldn't compile, but I fixed that by changing this in as_scriptengine.cpp: void *asCScriptEngine::CallAlloc(int objTypeIdx) { asCObjectType *type = allObjectTypes[objTypeIdx]; void *(*custom_alloc)(asUINT); if( type->beh.alloc ) { asSSystemFunctionInterface *intf = systemFunctionInterfaces[-type->beh.alloc - 1]; custom_alloc = (void *(*)(asUINT))intf->func; } else // old line custom_alloc = malloc; // new line custom_alloc = (void*(*)(asUINT))malloc; return custom_alloc(type->size); } It now compiles and creates the libangelscript.so file - no problems, but when I attempt to link to it, I get the following errors: /usr/local/lib/libangelscript.so: undefined reference to `DetectCallingConvention(char const*, asUPtr&, int, asSSystemFunctionInterface*)' /usr/local/lib/libangelscript.so: undefined reference to `PrepareSystemFunction(asCScriptFunction*, asSSystemFunctionInterface*, asCScriptEngine*)' /usr/local/lib/libangelscript.so: undefined reference to `CallSystemFunction(int, asCContext*, void*)' collect2: ld returned 1 exit status I'm using gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3) A quick search of the source reveals the following for CallSystemFunction [root@opteron source]# grep CallSystemFunction * as_callfunc.h:int CallSystemFunction(int id, asCContext *context, void *objectPointer); as_callfunc_sh4.cpp:int CallSystemFunction(int id, asCContext *context, void *objectPointer) as_callfunc_x86.cpp:int CallSystemFunction(int id, asCContext *context, void *objectPointer) as_context.cpp: l_sp += CallSystemFunction(i, this, 0); as_context.cpp: l_sp += CallSystemFunction(func, this, mem); as_context.h:// friend int CallSystemFunction(int id, asCContext *context); as_context.h: friend int CallSystemFunction(int id, asCContext *context, void *objectPointer); as_context_x86.cpp:static void *global_CallSystemFunction = (int (*)(int, asCContext*, void*))CallSystemFunction; as_context_x86.cpp: call global_CallSystemFunction as_context_x86.cpp: call global_CallSystemFunction // f(func, this, mem) as_scriptengine.h:// friend int CallSystemFunction(int id, asCContext *context); as_scriptengine.h: friend int CallSystemFunction(int id, asCContext *context, void *objectPointer); I thought that perhaps the some of the declarations were missing the last parameter, but that didn't work - it still compiles, but still missing references. I've reached the end of what I can attempt to do to fix it. Any advice? Thanks

I don't use AngelScript, but because of you postr I downloaded and built it on my Linux box (I'm looking for a nice embedded scripting language anyway, so it's not a complete waste of my time).

It builds fine for me without changes to any files except the mingw makefile. How are building the DSO?

I built, linked, and ran the test_feature suite (again without changes except to the mingw makefile) without any problems.

My DSO doesn't have any unexpected undefined symbols:

$ nm -u angelscript/lib/libangelscript.so | c++filt          U __assert_fail@@GLIBC_2.0         U __cxa_atexit@@GLIBC_2.1.3         w __cxa_finalize@@GLIBC_2.1.3         U __cxa_pure_virtual@@CXXABI_1.2         U fmodf@@GLIBC_2.0         U fmod@@GLIBC_2.0         U free@@GLIBC_2.0         w __gmon_start__         U __gxx_personality_v0@@CXXABI_1.2         w _Jv_RegisterClasses         U malloc@@GLIBC_2.0         U memcmp@@GLIBC_2.0         U memcpy@@GLIBC_2.0         U memset@@GLIBC_2.0         U strcmp@@GLIBC_2.0         U strlen@@GLIBC_2.0         U strtod@@GLIBC_2.0         U strtol@@GLIBC_2.0         U strtoul@@GLIBC_2.0         U _Unwind_Resume@@GCC_3.0         U vsnprintf@@GLIBC_2.0         U operator delete[](void*)@@GLIBCPP_3.2         U operator delete(void*)@@GLIBCPP_3.2         U operator new[](unsigned int)@@GLIBCPP_3.2         U operator new(unsigned int)@@GLIBCPP_3.2         U vtable for __cxxabiv1::__class_type_info@@GLIBCPP_3.2         U vtable for __cxxabiv1::__si_class_type_info@@GLIBCPP_3.2         U vtable for __cxxabiv1::__vmi_class_type_info@@GLIBCPP_3.2

I noticed that the hostname of your Linux box is 'opteron'. Does that also mean you're using an AMD Opteron processor, and running a 64-bit Linux distribution? If so, I'd say this is where your problem lies. It looks like AngelScript hasn't been ported to the x86_64 architecture, so some of the architecture-dependant code is probably not being built on your box.

If you don't need to build AngelScript (and whatever you're linking AngelScript into) as a 64-bit binary, you could try rebuilding everything with the '-m32' switch specified for the gcc command-line. This will generate 32-bit x86 binaries, which should run fine on a 64-bit Linux distro (albeit in 32-bit mode, natch) assuming the usual 32-bit emulation stuff is set up--chances are that it will be.

Hi

Ah - that would make sense.

Using the -m32 switch results in a library - but now this:

/usr/bin/ld: skipping incompatible /usr/local/lib/libangelscript.so when searchi
ng for -langelscript
/usr/bin/ld: cannot find -langelscript
collect2: ld returned 1 exit status

Doh! - Does that mean I can't link with 32bit and 64bit librarys at the same time?

Thanks

Correct--the 32-bit x86 and 64-bit x86_64 ABIs are not compatible, and the linker is protecting you from making a big mistake. You'll need to rebuild you project with the '-m32' switch as well.

AngelScript hasn't been ported to 64bit processors yet. If you'd like to give it a try that would be great. :)

However, I'm not sure that is the real problem. The functions that give undefined references are all implemented in the file as_callfunc_x86.cpp.

as_callfunc_x86.cpp and as_callfunc_sh4.cpp are two different implementations of the same functions. Which version that will be used in the compiled library is defined by the flags AS_X86 and AS_SH4 which are set in as_config.h. as_config.h defines AS_X86 on GNUC/Linux if the preprocessor flag i386 is defined. Since you have a 64bit processor it is possible the i386 flag isn't defined which would lead to the compiler ignoring the implementation of these functions.

If you can't get this to work, then it is possible to modify the library so that these functions aren't used. Unfortunately it would mean that only the AS_CALL_GENERIC calling convention can be used. I'll help you do this if you need it (it's something that I have been planning to do anyway with a preprocessor flag).

Regards,
Andreas