Sign in to follow this  
Followers 0
Guest afeder

Android port

272 posts in this topic

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 :)

Share this post


Link to post
Share on other sites

Very good good.gif 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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 laugh.gif

Share this post


Link to post
Share on other sites

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.?

Share this post


Link to post
Share on other sites

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).

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 by afeder

Share this post


Link to post
Share on other sites

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).

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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. blush.gif

Edited by afeder

Share this post


Link to post
Share on other sites

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 by afeder

Share this post


Link to post
Share on other sites

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 :))

Share this post


Link to post
Share on other sites
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.)

Share this post


Link to post
Share on other sites
(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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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

Works flawlessly for me.

Share this post


Link to post
Share on other sites

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 :)

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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 by afeder

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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 by afeder

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0