Port Ogre to Android?

[calsmurf2904]

Thats my main concern, we can't create a fork since it will be pointless then to create an application since it won't run on the default Google Android, only on the forked version. And 99,99 percent of the users use the default one.

[liberator]

Exactly,.. which is why I think you will have to come up with something the Google Dev's will allow into the official build once it has proven to be stable OR something you can install in user-space as part of an app. The latter would be the best, if technically possible, since it would make apps work right away and later after it has proven itself the Google dev's can still put it in their disto reducing bloat of app packages.

[calsmurf2904]

Well, looking at the GCC sources Google Android uses it seems they do have the files for exception etc. They just disabled it.
http://android.git.kernel.org/?p=toolch ... 95729c0779
Look for libsupc++, this lib handles RTTI, Exceptions and other stuff.

I guess just recompiling it with the exception flag on would enable it all.

Edit
Found out their makefile for G++ passes -fno-exceptions flag to G++. So it doesn't get compiled with it, I'm gonna try compiling it without the -fno-exceptions flag. (Probably some more stuff have to be added to make it work).

[liberator]

I think its fine if the C functions on all the Android libs don't throw exceptions or support them in any way shape or form. C++ Exceptions belong in C++ exclusively nowhere else. Its enough to add exception support to the point where application code can use exceptions internally but only within the confines of that bucket. It gives you a lot of code reuse without compromising the Android libs with a feature only C++ programmers need who have existing code or refuse to adapt to the non-use of exceptions.

Basically I would maintain the rule of thumb that any solution in this area should not compromise/alter the existing Android libs in any way and only expand uppon them in a non-intrusive way. I believe anything else simply won't be accepted by the Android dev's or the large percentage of the Android community who have no use for C++ exception support.

[calsmurf2904]

When compiling with the -fno-exceptions we are actually forking their GCC version, but it should only make changes to the applications compiled with it. Since we don't edit libc, nor recompile it it should still run on the android devices. (Since libc defines the crt0 etc.). The only changes are going to be in libstdc++, it will get compiled with exceptions and RTTI instead of without. But this is only application side stuff, no problems with their OS.

[liberator]

I see. Do you think this recompiled libstdc++ can be distributed with apps and run without root privileges?

[calsmurf2904]

Well, it does depend on libc....which Android provide. But normally it also runs without root privileges (each linux application links to it so that it can use the std stuff).

Edit
The only problem is that I don't have linux or mac OSX, and android compile pages say they don't support windows yet.

[liberator]

You could run it in a VM short-term for some experimentation,.. VMWare has a free solution for small scale stuff.

[calsmurf2904]

Or use virtualbox, I'm wondering though, how did they build the windows version of their NDK when its not supported?

Edit
I found this: http://wiki.gnashdev.org/Building_for_Android, it seems that guy has been building gcc himself since the NDK wasn't released at that time.
Dunno how far he got, but it seems he got it compiled atleast. (He's trying to compile the full gcc, so without the changed libstdc++ etc).

[Praetor]

I've compiled some stuff with the NDK using mingw on windows.

Let me get this straight. They provide a c++ runtime without any of th extras turned on. You recompiled the same thing with the extras turned on. Theoretically we can just package this new runtime with our libs and it will run with no issue? That's pretty cool. From what I can tell they claimed at the time the GCC version with exceptions on KILLED their performance. Compiling with the latest GCC should hopefully avoid performance problems. If this works, you are my new hero.

[calsmurf2904]

I haven't recompiled anything yet, seems that guy compiled a gcc capable of compiling for android before the NDK was even released. I'm gonna try to compile a version with the android edited libc etc. so it runs faster and with RTTI and Exceptions on. I'm gonna try it with MSYS and MingW on windows (Since I am a windows user, I might try it on linux later on).

Edit
To be precise: GCC 4.4.0

[calsmurf2904]

Alright, already compiled binutils (MingW is no go, it has some bug or something that prevents it from compiling, I'm now just using cygwin) and currently compiling GCC + G++.

[calsmurf2904]

Alright, the problem is that I got GCC and G++ fully compiled (latest version, 4.4.2) but I can't get android's libc compiled. I might need to get the regular libc compiled with the regular libstdc++, or port newlib over as libc (newlib is designed for embedded systems so the performance impact shouldn't be too big). Good thing that android's libc already defines the system calls that I need to implement in newlib for it too work, so that shouldn't be too big of a problem. The only problem is that the regular libstdc++ has to be compiled instead of android's libstdc++.

[Assaf Raman]

Sounds like you are on the right way, don't give up.

[calsmurf2904]

Ok, ported over newlib (that means we got a fully featured libc & libm now!) but I'm having configure problems with libstdc++-v3:

Code: Select all

$ ./configure --target=$TARGET --prefix=$PREFIX --disable-nls --with-newlib CPP=arm-none-eabi-gcc CXXPP=arm-none-eabi-g++
checking build system type... i686-pc-cygwin
checking host system type... i686-pc-cygwin
checking target system type... arm-none-eabi
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking how to run the C preprocessor... arm-none-eabi-gcc
configure: error: in `/cygdrive/c/AndroidNDK/gcc-4.4.2/libstdc++-v3':
configure: error: C preprocessor "arm-none-eabi-gcc" fails sanity check
See `config.log' for more details.

config.log says this:

Code: Select all

configure:2346: arm-none-eabi-gcc  conftest.c
conftest.c:14: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'error'
configure:2352: $? = 1
configure: failed program was:
| /* confdefs.h.  */
| 
| #define PACKAGE_NAME "package-unused"
| #define PACKAGE_TARNAME "libstdc++"
| #define PACKAGE_VERSION "version-unused"
| #define PACKAGE_STRING "package-unused version-unused"
| #define PACKAGE_BUGREPORT ""
| /* end confdefs.h.  */
| #ifdef __STDC__
| # include <limits.h>
| #else
| # include <assert.h>
| #endif
| 		     Syntax error
configure:2346: arm-none-eabi-gcc  conftest.c
conftest.c:14: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'error'
configure:2352: $? = 1
configure: failed program was:
| /* confdefs.h.  */
| 
| #define PACKAGE_NAME "package-unused"
| #define PACKAGE_TARNAME "libstdc++"
| #define PACKAGE_VERSION "version-unused"
| #define PACKAGE_STRING "package-unused version-unused"
| #define PACKAGE_BUGREPORT ""
| /* end confdefs.h.  */
| #ifdef __STDC__
| # include <limits.h>
| #else
| # include <assert.h>
| #endif
| 		     Syntax error
configure:2420: error: in `/cygdrive/c/AndroidNDK/gcc-4.4.2/libstdc++-v3':
configure:2423: error: C preprocessor "arm-none-eabi-gcc" fails sanity check
See `config.log' for more details.

And I have no idea howto fix this, maybe somebody could help me who knows a bit more about linux and gcc.

[Assaf Raman]

I searched google, here are the links I found:
http://zacster.blogspot.com/2008/04/con ... ibcpp.html
http://worldforum.pardus-linux.nl/index ... pic=2864.0
http://bbs.archlinux.org/viewtopic.php?id=70724

Probably won't help you, but have a look...

[calsmurf2904]

lol, looking at it it seems that he thinks "| Syntax error" is part of the code. Might be something cygwin related, since the default gcc (not the arm-none-eabi-gcc) also gives the same error.

[calsmurf2904]

Code: Select all

$ ./configure --target=$TARGET --prefix=$PREFIX --disable-nls --with-newlib CPP=arm-none-eabi-gcc CXXPP=arm-none-eabi-g++
checking build system type... i686-pc-cygwin
checking host system type... i686-pc-cygwin
checking target system type... arm-none-eabi
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking how to run the C preprocessor... arm-none-eabi-gcc
configure: error: in `/cygdrive/c/AndroidNDK/gcc-4.4.2/libstdc++-v3':
configure: error: C preprocessor "arm-none-eabi-gcc" fails sanity check
See `config.log' for more details.

See the CPP=arm-none-eabi-gcc line in the configure command? when I changed it to "arm-none-eabi-gcc -E" it works (well, it configures)
So the full command becomes:

Code: Select all

./configure --target=$TARGET --prefix=$PREFIX --disable-nls --with-newlib CPP="arm-none-eabi-gcc -E" CXXPP=arm-none-eabi-g++

[Assaf Raman]

Nice work, so what are you working on now?

[calsmurf2904]

Compiling libstdc++, then I would need to find out where in the HUGE android source they hid the opengl es lib and compile it. We probably need to port over some screen management code to ogre to make it work. (Custom OgreAndroidRenderWindow?).

[Assaf Raman]

Well, there is a 3d sample on the android NDK called san-angeles.

san-angeles — A simple application that renders 3D graphics through the native OpenGL ES APIs, while managing activity lifecycle with a GLSurfaceView object.

From what I can see you need a java bootstrap to start the c++ program.

[Assaf Raman]

Try to use your new libstdc++ with existing san-angeles demo - this will be a good step, then if it works - compile with an exception and RTTI test - to see that they are now supported, if so - post you work.

[calsmurf2904]

Thanks! We could probably use that as reference when creating the "OgreAndroidRenderWIndow". Still need to find the OpenGL ES Source code in the android source tree.

I've been thinking about the java stuff, what if we export the C++ main function from the application and call that from java? then we have some sort of JAVA crt0.

[calsmurf2904]

Have been trying to compile libstdc++ but I keep having compile errors, I'm now retrying with some different settings (mainly that I let the gcc configure script create the makefiles for libstdc++ instead of libstdc++ himself). I hope this will set some stuff that will make it compile correctly.

[calsmurf2904]

Better said, since its all about performance too, isn't STLport a better choice as STD instead of libstdc++? STLport seems to be designed for embedded systems, so that should be good. I dunno if it compiles with ogre though. Anybody daring to shed some light on this?

Nevermind, STLport doesn't support arm eabi processor, which the android has.