STK 0.9 fails to build on armel/armhf/arm64/ppc64el/s390x

[Vincent-C]

STK 0.9 (just uploaded today to Debian) fails to build on a variety of non-i386/amd64 architectures in Debian sid; see here for build status and logs (you can click on any of the rows under the "Status" column for the entire log for that arch). Note that STK 0.8.1 built fine on all archs supported by Debian.

All of the build failures have this in common:

/«PKGBUILDDIR»/lib/angelscript/source/as_callfunc_x64_gcc.cpp: In function 'asQWORD X64_CallFunction(const asQWORD*, int, funcptr_t, asQWORD&, bool)':
/«PKGBUILDDIR»/lib/angelscript/source/as_callfunc_x64_gcc.cpp:144:82: error: unknown register name '%rcx' in 'asm'
     "%rdi", "%rsi", "%rax", "%rdx", "%rcx", "%r8", "%r9", "%r10", "%r11", "%r15");
                                                                                  ^
/«PKGBUILDDIR»/lib/angelscript/source/as_callfunc_x64_gcc.cpp:144:82: error: unknown register name '%rdx' in 'asm'
/«PKGBUILDDIR»/lib/angelscript/source/as_callfunc_x64_gcc.cpp:144:82: error: unknown register name '%rax' in 'asm'
/«PKGBUILDDIR»/lib/angelscript/source/as_callfunc_x64_gcc.cpp:144:82: error: unknown register name '%rsi' in 'asm'
/«PKGBUILDDIR»/lib/angelscript/source/as_callfunc_x64_gcc.cpp:144:82: error: unknown register name '%rdi' in 'asm'
/«PKGBUILDDIR»/lib/angelscript/source/as_callfunc_x64_gcc.cpp:144:82: error: unknown register name '%xmm7' in 'asm'
/«PKGBUILDDIR»/lib/angelscript/source/as_callfunc_x64_gcc.cpp:144:82: error: unknown register name '%xmm6' in 'asm'
/«PKGBUILDDIR»/lib/angelscript/source/as_callfunc_x64_gcc.cpp:144:82: error: unknown register name '%xmm5' in 'asm'
/«PKGBUILDDIR»/lib/angelscript/source/as_callfunc_x64_gcc.cpp:144:82: error: unknown register name '%xmm4' in 'asm'
/«PKGBUILDDIR»/lib/angelscript/source/as_callfunc_x64_gcc.cpp:144:82: error: unknown register name '%xmm3' in 'asm'
/«PKGBUILDDIR»/lib/angelscript/source/as_callfunc_x64_gcc.cpp:144:82: error: unknown register name '%xmm2' in 'asm'
/«PKGBUILDDIR»/lib/angelscript/source/as_callfunc_x64_gcc.cpp:144:82: error: unknown register name '%xmm1' in 'asm'
/«PKGBUILDDIR»/lib/angelscript/source/as_callfunc_x64_gcc.cpp:144:82: error: unknown register name '%xmm0' in 'asm'

Does angelscript require porting assembly to various non-x86 archs? The weird thing is that STK 0.9 actually builds fine on some non-x86 archs, e.g. mipsel, and I'd be kinda surprised if some piece of software supported mips but not arm these days. However, it does in fact look like angelscript has been ported to arm (lib/angelscript/source/as_callfunc_arm.cpp); why is x86 assembly being used in the arm build then?

It seems to me that this is probably related to the build system somehow, but I'm not all that familiar with cmake; does anyone know what might be going on here?

[deveee]

Here is similar bug report: #2119 It seems to be something wrong with compiler definitions used in angelscript because function CallSystemFunctionNative is available in as_callfunc_arm.cpp and we get undefined reference... But I had only a very quick look on it. Btw. I noticed that you are trying to use system glew library. AFAIK we still need patched glew to make it work properly. @hiker do you remember what is precisely patched and why do we need it?

[jcowgill]

Was about to file a Debian bug when I noticed this one :)

All the 64-bit failures are caused by broken architecture detection here:
https://github.com/supertuxkart/stk-code/blob/master/lib/angelscript/source/as_config.h#L788

It assumes that x86_64 is the only arch which defines __LP64__ (and then gets the arm64 define wrong anyway).

[auriamg]

Could you perhaps test ir #if x86_64 works better? You seem to have access to more platforms than I do

[Vincent-C]

@jcowgill Admittedly I'm not all that familiar with porting to exotic archs, and don't know what preprocessor checks should be used instead; would you care to suggest the correct defines to be used here (or perhaps a patch)? Thanks!

@auriamg Sure, I'll prepare a PR once I've run a few test builds on some Debian porterboxen.

@deveee Thanks for the heads up re: glew. Interested in seeing what @hiker has to say, since I need some rationale before overriding lintian (glew happens to be one of the libs that lintian will detect when checking for embedded libraries) and choosing to use embedded libs.

[jcowgill]

I submitted #2195, hopefully it fixes this.

[auriamg]

After verifying, these architectures actually do not appear to be supported by angelscript ( see http://www.angelcode.com/angelscript/features.html ) - they are also pretty uncommon architectures so I don't think we care STK not running there

[hiker]

Re libglew: afaik the problem with libglew still exists. A patch has been supplied (2 years ago). Details in https://sourceforge.net/p/glew/patches/40/

So, till this is fixed upstream, we need our own patched libglew version.

[jcowgill]

From the angelcode features page:

CPU independent - Both 32bit and 64bit platforms are supported. Both big endian and little endian CPUs are supported. Confirmed CPUs: x86, amd64, sh4, mips, ppc, ppc64, arm.
[...]
Maximum portability mode - When the library is compiled in this mode it should work on just about any compiler/platform that can compile standard compliant C++ code. Some features like native calling conventions are not available in this mode.

So it should work on these arches.

[Vincent-C]

@jcowgill Thanks for the patch! Will apply it to the Debian package shortly.

@hiker Thanks for the explanation + link. I'll go ahead and revert the patch I added to Debian in 0.9-1 to use the system version of glew when building STK.

[auriamg]

Angelscript has been updated to a newer version, should hopefully be fixed now