Android port

[Ykkrosh]

The assert things just look like warnings, not errors, so they shouldn't be a problem and can be safely ignored.

If you're not running 'make' with the '-k' flag, you should probably add it (e.g. "make -k pyrogenesis config=debug" is probably the best thing for initial testing) and then you should get zillions more errors

[historic_bruno]

Very good I am now down to this error output, using Crystax NDK and the CONFIG2_GLES flag with the latest source.

I guess NDK doesn't provide POSIX asynchronous I/O either, maybe look into using Boost.Asio? If you look at posix_aio.h, we already emulate it on Windows (waio.h/cpp), so perhaps you could use Boost to provide the same interface? Doesn't sound trivial to me :/ Maybe AIO can be avoided in your case. I'm guessing Jan wrote all that code, maybe you could ask him for advice.

[Ykkrosh]

I think we don't use async IO on Linux anyway (because a kernel bug broke it, and it provides little benefit) - sync IO works well enough. I expect we can get rid of the build errors by possibly moving some code into "#if CONFIG2_FILE_ENABLE_AIO" blocks, and possibly by defining some macros (LIO_READ etc) and structs (aiocb etc) ourselves when the platform doesn't provide them.

[historic_bruno]

Good to know, that simplifies things a bit

[Guest afeder]

The assert things just look like warnings, not errors, so they shouldn't be a problem and can be safely ignored.

If you're not running 'make' with the '-k' flag, you should probably add it (e.g. "make -k pyrogenesis config=debug" is probably the best thing for initial testing) and then you should get zillions more errors

*reloads shotgun* Bring it.

Doesn't seem too bad. Maybe it was overwhelmed and broke down

[Guest afeder]

I think we don't use async IO on Linux anyway (because a kernel bug broke it, and it provides little benefit) - sync IO works well enough. I expect we can get rid of the build errors by possibly moving some code into "#if CONFIG2_FILE_ENABLE_AIO" blocks, and possibly by defining some macros (LIO_READ etc) and structs (aiocb etc) ourselves when the platform doesn't provide them.

Can you elaborate on how you think this should be approached? What parts of the code should be put into "#if CONFIG2_FILE_ENABLE_AIO" blocks, how should it detect whether the platform provides the relevant macros and structs, etc.?

[Ykkrosh]

You should do this . Also, it looks like you're setting up ndk-build to only build main.cpp and none of the rest of the game - it'd probably be better to build with Premake as normal, like here (though that'll need lots of fixes to support cross-compilation before it'll work for real; but at least it gets far enough to highlight lots of build fixes that will need fixing first).

[Guest afeder]

You should do this . Also, it looks like you're setting up ndk-build to only build main.cpp and none of the rest of the game - it'd probably be better to build with Premake as normal, like here (though that'll need lots of fixes to support cross-compilation before it'll work for real; but at least it gets far enough to highlight lots of build fixes that will need fixing first).

Great. That should keep me busy.

[Guest afeder]

You should do this . Also, it looks like you're setting up ndk-build to only build main.cpp and none of the rest of the game - it'd probably be better to build with Premake as normal, like here (though that'll need lots of fixes to support cross-compilation before it'll work for real; but at least it gets far enough to highlight lots of build fixes that will need fixing first).

When I run update-workspaces.sh, I get the following error:

afeder@ubuntu:~/android/0ad/build/workspaces$ ./update-workspaces.sh --gles
Updating bundled third-party dependencies...

bash -c 'mkdir -p output/{debug,release,test}/{FCollada/{FCDocument,FMath,FUtils,FColladaTest/{FCTestAssetManagement,FCTestExportImport,FCTestXRef}},FColladaPlugins/FArchiveXML}'
cp output/libFColladaSD.a ../lib/libFColladaSD.a
cp output/libFColladaSR.a ../lib/libFColladaSR.a

Building SpiderMonkey...

SpiderMonkey build options: --disable-tests 		
loading cache ./config.cache
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking build system type... x86_64-unknown-linux-gnu
checking for mawk... mawk
checking for perl5... no
checking for perl... /usr/bin/perl
checking for gcc... gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking for c++... arm-linux-androideabi-g++
checking whether the C++ compiler (arm-linux-androideabi-g++  ) works... no
configure: error: installation or configuration problem: C++ compiler cannot create executables.
ERROR: SpiderMonkey build failed

This is the config.log: http://pastebin.com/5AFZG4CX

It says "eval: 1: arm-linux-androideabi-g++: not found", but if I run "arm-linux-androideabi-g++" from the command-line, it finds it well enough, so the PATH should be set up correctly.

Edited January 20, 2012 by afeder

[Ykkrosh]

You should run update-workspaces.sh after setting HOSTTYPE, but before setting PATH or CXX or anything else. That will build the bundled libraries (SpiderMonkey etc) like in a normal non-Android build with the standard x86/amd64 version of GCC - those libraries won't be usable by an Android version of the game but we can deal with that problem later once the game's compile errors are fixed.

Then set PATH and CXX, and run the 'make' command from inside workspaces/gcc/ (like in a normal build of the game, except now it's using the Android compiler).

[Guest afeder]

You should run update-workspaces.sh after setting HOSTTYPE, but before setting PATH or CXX or anything else. That will build the bundled libraries (SpiderMonkey etc) like in a normal non-Android build with the standard x86/amd64 version of GCC - those libraries won't be usable by an Android version of the game but we can deal with that problem later once the game's compile errors are fixed.

Then set PATH and CXX, and run the 'make' command from inside workspaces/gcc/ (like in a normal build of the game, except now it's using the Android compiler).

Yup, that did the trick.

[Guest afeder]

Does the Premake build system override the compiler sysroot somehow? I get errors of this type when running make:

../../../source/lib/external_libraries/opengl.h:40:24: fatal error: GLES2/gl2.h: No such file or directory

Even though the file should exist:

afeder@ubuntu:~/android/0ad/build/workspaces/gcc$ ls `$CXX -print-sysroot`/usr/include/GLES2/gl2.h
/home/afeder/android/toolchain/bin/../sysroot/usr/include/GLES2/gl2.h

Edit: it seems the issue was that the makefile doesn't honor the $CXX environment variable - I had to pass it as a command-line option instead.

Edit2: my bad - I had failed to export the variable.

Edited January 23, 2012 by afeder

[Guest afeder]

I've cross-compiled Boost, SDL, libcurl, libpng and libjpeg under the setup Ykkrosh suggested. My error output now looks like this. As you can see, it's mostly down to graphics and sound (though I haven't dealt with the bundled dependencies yet.)

A few questions:

- What does the game use FAM for and is there some way to disable it (at build time)?

- Does the game use libogg and libvorbis for anything but simple playback of sound and music assets? If not, I suggest porting those parts to OpenSL ES, as it supports this natively, meaning less risk of breakage (it's maintained by Google/handset manufacturers) and better utilization of device-specific features like ARM NEON (i.e. better performance).

Edited January 28, 2012 by afeder

[Ykkrosh]

Looks great so far

- What does the game use FAM for and is there some way to disable it (at build time)?

It's used for detecting changes to files (so e.g. a modder can edit a texture and immediately see the changes in the game). The game will work fine without it.

We currently have this platform-specific code in source/lib/sysdep/os/. Windows uses the "win" directory, Linux uses "linux" plus "unix" plus "unix/x", OS X uses "osx" plus "unix" plus "unix/x". Android should probably still use the "linux" directory, since it runs the Linux kernel and most of that code is relevant; it's not really a separate OS. (Also it should use "unix" but not "unix/x"). I suppose FAM/Gamin support is technically orthogonal to OS/kernel/etc - currently Gamin is only implemented on Linux but the API could work anywhere - so it's theoretically inappropriate to have it in the "linux" directory, and we theoretically probably ought to arrange things based on feature-detection rather than on detected OS... But that sounds like a lot of effort, so in practice I'll probably add some #define to just cut out the FAM code.

- Does the game use libogg and libvorbis for anything but simple playback of sound and music assets?

Depends what "simple" means, but we only use them for playback. Probably the best thing in the short term is to just #ifdef out all the problematic sound code, since we'll probably redesign most of that code in the future anyway so there's not point porting it yet.

(Incidentally, I'm planning to get an Android phone (Galaxy S II) in the next few days, so this might become of more than hypothetical interest to me )

[Ykkrosh]

Committed a few more fixes (with Premake flags --without-fam, --without-audio to disable the offending features for now). Now the only compile errors I get in the 'lowlevel' project are ogl_shader.cpp, plus some because I haven't bothered installing libpng/libjpeg yet. (There's going to be lots of link errors later though.)

[Guest afeder]

(Incidentally, I'm planning to get an Android phone (Galaxy S II) in the next few days, so this might become of more than hypothetical interest to me )

Great. I'll add it to the 'Target devices' section

Committed a few more fixes (with Premake flags --without-fam, --without-audio to disable the offending features for now). Now the only compile errors I get in the 'lowlevel' project are ogl_shader.cpp, plus some because I haven't bothered installing libpng/libjpeg yet. (There's going to be lots of link errors later though.)

What link errors do you foresee (other than the bundled dependencies)? What is not accounted for by the current setup?

[Ykkrosh]

What link errors do you foresee (other than the bundled dependencies)?

There needs to be some new code added, equivalent to lib/sysdep/os/unix/x/x.cpp (should be mostly trivial), and lib/sysdep/arch/x86_x64/x86_x64.h and lib/sysdep/arch/ia32/ia32.cpp (probably not too hard). I suppose that's not really a lot, and linker errors will point out exactly which functions are missing, so it shouldn't be a big problem.

[Pureon]

I'm planning to get an Android phone (Galaxy S II) in the next few days

Works flawlessly for me.

[WhiteTreePaladin]

Galaxy S III

[Ykkrosh]

Yeah, anything available now will be totally obsolete within six months . But it seems nice enough for now, and relatively good value ('free' with £24/month * 24 month contract, via O2), so I think I'll be adequately happy

[Pureon]

But it seems nice enough for now, and relatively good value ('free' with £24/month * 24 month contract, via O2), so I think I'll be adequately happy

That's much better than what I paid/pay for mine btw

[Guest afeder]

I am consistently getting this error when building the game:

In file included from /usr/include/libxml2/libxml/parser.h:807,
 				from /usr/include/libxml2/libxml/hash.h:29,
 				from /usr/include/libxml2/libxml/relaxng.h:14,
 				from ../../../source/ps/XML/RelaxNG.cpp:26:
/usr/include/libxml2/libxml/encoding.h:28:19: error: iconv.h: No such file or directory
In file included from /usr/include/libxml2/libxml/parser.h:807,
 				from /usr/include/libxml2/libxml/hash.h:29,
 				from /usr/include/libxml2/libxml/relaxng.h:14,
 				from ../../../source/ps/XML/RelaxNG.cpp:26:
/usr/include/libxml2/libxml/encoding.h:146: error: 'iconv_t' does not name a type
/usr/include/libxml2/libxml/encoding.h:147: error: 'iconv_t' does not name a type
make[1]: *** [obj/engine_Debug/RelaxNG.o] Error 1

Even though I have built libxml2 without bindings to iconv and hand-edited encoding.h to remove any reference to it:

afeder@ubuntu:~/android/0ad-game/build/workspaces/gcc$ cat $SYSROOT/usr/include/libxml2/libxml/encoding.h | grep iconv
afeder@ubuntu:~/android/0ad-game/build/workspaces/gcc$

I suspect the compiler is loading the encoding.h in my machine's absolute root instead of the $SYSROOT. Any idea why that might be happening? Perhaps there needs to be a --with-sysroot option in update-workspaces.sh? (I see many other packages has this.)

My environment seems right this time:

afeder@ubuntu:~/android/0ad-game/build/workspaces/gcc$ echo $SYSROOT
/home/afeder/android/toolchain/sysroot
afeder@ubuntu:~/android/0ad-game/build/workspaces/gcc$ echo $CXX
arm-linux-androideabi-g++

Edited January 31, 2012 by afeder

[historic_bruno]

I suspect the compiler is loading the encoding.h in my machine's absolute root instead of the $SYSROOT. Any idea why that might be happening? Perhaps there needs to be a --with-sysroot option in update-workspaces.sh? (I see many other packages has this.)

Premake uses pkg-config to get the include paths for various packages like libxml2. So what's the result of running "pkg-config libxml-2.0 --cflags"? Are the other dependencies that use pkg-config compiling the correct files?

[Guest afeder]

Premake uses pkg-config to get the include paths for various packages like libxml2. So what's the result of running "pkg-config libxml-2.0 --cflags"? Are the other dependencies that use pkg-config compiling the correct files?

This is the result:

afeder@ubuntu:~/android/toolchain/sysroot/usr/include/libxml2$ pkg-config libxml-2.0 --cflags
-I/usr/include/libxml2

That should be good enough, if the compiler interprets it relative to $SYSROOT:

afeder@ubuntu:~/android/toolchain/sysroot/usr/include/libxml2$ ls $SYSROOT/usr/include/libxml2
libxml

I can't positively tell whether the other dependencies are included correctly, but at least I have not encountered other errors of this type. And the errors that I did encounter went away when I fixed them in the sysroot - not in the absolute root.

Edited January 31, 2012 by afeder

[historic_bruno]

That should be good enough, if the compiler interprets it relative to $SYSROOT:

According to your error, it's not I've never heard of SYSROOT, if it's something that gets passed to e.g. ./configure, that's a step before the compilation and means the build system is indeed responsible for configuring the path correctly. Apparently there's a variable called "PKG_CONFIG_SYSROOT_DIR" which tells pkg-config to prepend something to its paths, can you try setting that and see what happens? It's listed here under Environment Variables.