ARM build issues

[fabio]

Recently after fixing nvtt package Debian and Ubuntu also enabled building armel and armhf 0ad. Both builds fail with different issues. The latest build status and logs are available here: ​https://buildd.debian.org/status/package.php?p=0ad&suite=sid

The arm specific build log are available at:

• armel: ​https://buildd.debian.org/status/logs.php?pkg=0ad&arch=armel
• armhf: ​https://buildd.debian.org/status/logs.php?pkg=0ad&arch=armhf

1) armel (fixed in SVN?)

fails with:

FCollada/FMath/FMRandom.cpp
FCollada/FMath/FMSkew.cpp
FCollada/FMath/FMVector3.cpp
FCollada/FMath/FMVolume.cpp
FCollada/FUtils/FUAssert.cpp
FCollada/FUtils/FUBase64.cpp
/tmp/ccEqcoJM.s: Assembler messages:
/tmp/ccEqcoJM.s:156: Error: selected processor does not support ARM mode `bkpt 0'
make[2]: *** [output/debug/FCollada/FUtils/FUAssert.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory `/«PKGBUILDDIR»/libraries/source/fcollada/src'
make[1]: *** [override_dh_auto_build] Error 1
make: *** [build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2
ERROR: FCollada build failed

2) armhf on Ubuntu 12.04

fails with:

../../../source/simulation2/helpers/Geometry.cpp: In function 'bool Geometry::TestRaySquare(CFixedVector2D, CFixedVector2D, CFixedVector2D, CFixedVector2D, CFixedVector2D)':
../../../source/simulation2/helpers/Geometry.cpp:239:1: error: unable to find a register to spill in class 'LO_REGS'
../../../source/simulation2/helpers/Geometry.cpp:239:1: error: this is the insn:
(insn 75 20 17 2 (set (reg/v:DI 141 [ sum ])
        (plus:DI (mult:DI (sign_extend:DI (reg:SI 245 [ a$value ]))
                (sign_extend:DI (reg:SI 241 [ u$value ])))
            (reg/v:DI 141 [ sum ]))) ../../../source/maths/FixedVector2D.h:200 49 {*mulsidi3adddi_v6}
     (nil))
../../../source/simulation2/helpers/Geometry.cpp:239: confused by earlier errors, bailing out

3) SSE warning:

when running test on a proper architecture this is printed:

No SSE available. Slow fallback routines will b used.

The message should be updated.

[Josh]

Don't know what I was thinking with the compiler options... I'll try to get a patch for armhf later today, the armel issue will be a lot harder for me to debug because I don't have any platform to test on. But, that said, I know a number of things that aren't keyed for armel and assume hard float which I can try to fix. Also, the SSE warning I've been told is not important, so we don't need to worry about that (But I'll try to look at the code anyway).

[leper]

armel can quite possibly be fixed by exchanging the arm specific (and I guess only certain versions of it) inline assembly in FUAssert.cpp​ by testing for something GCC-compatible first and using __builtin_trap().

[fabio]

Is neon really required or make at least a noticeable performance difference? Some not so old CPU ( e.g. Tegra 2 ​http://en.wikipedia.org/wiki/Tegra#Tegra_2 ) lacks it.

[fabio]

Also I wonder if -mtune=generic-arm is also needed or it's best to use the system default one, with the trick here ​http://gcc.gnu.org/ml/gcc-help/2011-11/msg00250.html is possible to see what is used by default.

[fabio]

I mean, what about removing completely -mtune options and just using the system default, whatever it is on the platform? Also the NEON comments should be removed if -mfpu=neon is removed.

[Josh]

Optimize for armv7-a, but maintain backward compatibility for older instruction sets. Use default FPU and ABI. (Updated comments)

[Josh]

The reason I'm using mtune, is because the build/test machine could potentially be on an older instruction set then client machines. For example, the Debian armel build machine is on armv5 while most modern devices should run armv7; using mtune we can still compile and run those tests on the older instruction set while leaving our target platform (armv7) with a performance increase.

While, on the other hand, using the defaults would cause the code to be optimized for the build platform (armv5) resulting in potentially slower performance on our primary target platform (armv7).

[fabio]

This is reasonable.

[Vincent Cheng]

Quick update: I've re-uploaded 0ad to Debian with Josh's patch above, and 0ad now builds successfully on Debian armhf, but still fails to build with armel (tail of build log is still the same).

FCollada/FUtils/FUBase64.cpp
/tmp/ccuVlBMO.s: Assembler messages:
/tmp/ccuVlBMO.s:156: Error: selected processor does not support ARM mode `bkpt 0'
make[2]: *** [output/debug/FCollada/FUtils/FUAssert.o] Error 1

[Josh]

Hopefully resolve the remaining issues.

[Josh]

Fix windows build and remove extraneous flags.

[JoshuaJB]

In 14050:

Make the *nix ARM support a little sturdier, Fixes #2121

[fabio]

After latest changes armhf failed to build in the PPA: ​https://launchpad.net/~wfg/+archive/0ad.dev/+packages

[Josh]

Reviewing the build log, ​https://launchpad.net/~wfg/+archive/0ad.dev/+builds?build_text=&build_state=all, it appears to me that only the precise build failed. If I read that correctly all the newer versions of Ubuntu build 0AD armhf just fine.

(I'm also having some trouble pinpointing where things are failing in the precise build log, if someone could highlight where it's failing that would be helpful.)

[fabio]

You are right, only the precise build is failing, I missed that. It can probably be ignored if it's due to old gcc or other software. The error is this:

../../../source/simulation2/helpers/Geometry.cpp: In function 'bool Geometry::TestRaySquare(CFixedVector2D, CFixedVector2D, CFixedVector2D, CFixedVector2D, CFixedVector2D)':
../../../source/simulation2/helpers/Geometry.cpp:239:1: error: unable to find a register to spill in class 'LO_REGS'
../../../source/simulation2/helpers/Geometry.cpp:239:1: error: this is the insn:
(insn 75 20 17 2 (set (reg/v:DI 141 [ sum ])
        (plus:DI (mult:DI (sign_extend:DI (reg:SI 245 [ a$value ]))
                (sign_extend:DI (reg:SI 241 [ u$value ])))
            (reg/v:DI 141 [ sum ]))) ../../../source/maths/FixedVector2D.h:200 49 {*mulsidi3adddi_v6}
     (nil))
../../../source/simulation2/helpers/Geometry.cpp:239: confused by earlier errors, bailing out

[Josh]

Updated the description to reflect current status. I'd like to make sure A15 will build on armhf and armel without patching.

[Vincent Cheng]

Just a quick update for Alpha 15, now that it's been packaged and built on Debian and Ubuntu:

​https://buildd.debian.org/status/package.php?p=0ad

Debian armel no longer has any build failures, but it seems to segfault when running the test suite. From the build log:

cd binaries/system/ && LD_LIBRARY_PATH=. ./test -libdir .
Segmentation fault

That probably isn't helpful at all...anyways, if getting this fixed is too much trouble, I could just skip running the test suite on Debian armel.

Alpha 15 builds fine on Debian/Ubuntu armhf.

[Josh]

Thanks for the update, I'm glad armhf and armel are building successfully now but the armel crash isn't really debuggable because I'm not aware of anyone on the team who has an armel device.

If you'd like you could disable the tests on armel, but that's something that should be fixed.

At the Ubuntu 12.04 build issue fabio was encountering, I'm going to leave that as won't fix because the next Ubuntu LTS is rolling around soon and 12.04 is going to become less relevant.

I'll close this since it's related to build failures and open a new ticket for the armel segfault.