Port Ogre to Android?

[Praetor]

It seem limited. The core problem is that the Android developers have a working system and unwilling to tinker with it. I can understand that since it is solid they do not want to make the changes necessary, but at the same time they are cutting out a huge percentage of C++ systems from working. I can't justify creating a fork of Ogre mangled in order to run on the platform. They mention that one can add in exception support to the OS (I mean Android is open source) but that's just a big catch-22. Will our changes go into any official updates, or will we end up with an orphaned version that never gets pushed to any real devices? In the end I think the core Android devs are the ones who have to make this change and they aren't budging.

[Assaf Raman]

Look at the latest post, that guy says he created a lib for Android that allows exception handling. Dunno how good it is though.

I saw that before posting the link, not relevant, too limited.

[calsmurf2904]

People could port over newlib and then port over libstdc++. (Instead of the smaller google android libc). Then we could use all the std stuff and use exceptions + RTTI. This would allow us to port over Ogre. (Someone should goto the trouble of doing this though).

Edit
Something like this would do it I think: http://www.openhardware.net/Embedded_ARM/Toolchain/

[Assaf Raman]

Sounds hard. Look at this thread.

[calsmurf2904]

Seems like we got a good reason Newlib shouldn't be hard to port over (we just have to provide it a few files so that it can execute some common functions like fopen etc.) and disregarding the small battery life libstdc++ could be ported over not very hard too. I could try this sometime, unfortunately I don't have an android device.

[liberator]

The Android version of libstdc++ has a lot of optimizations you don't want to through out with the dishwater. So what I'm wondering is,... Would it not be more feasible to setup your toolchain such that you link to an extended version of Android's libstdc++ (lets call this fictional module "extended-libstdc++" for sake of argument) which will proxy all existing libstdc++ functionality to the normal Android version but in addition expands upon the functionality within the "extended-libstdc++" module itself.

[calsmurf2904]

So instead of porting over libstdc++ to Google Android you suggest we port over the rest of libstdc++ that Google Android doesn't have yet to the Google Android libstdc++? (Just want to make sure I get it )

Edit
But what if the google devs update their libstdc++ version? we would then need to update ours to their updates each time, which would mean alot of changing again. We would be better off if we could use the standard libstdc++ even if it isn't optimized. More for testing purposes. If they performance is low we could goto plan B, change the android libstdc++ to fit to Ogre's needs.

[liberator]

Basically,.. yea,... In a way that you create a libstdc++ for Android which is not a replacement but rather an expansion upon what Android offers in a way developers can easily link to and which additionally but most importantly does not impact the existing Android modules mitigating the fears of the Android dev's that the tinkering will make the platform unstable altogether for apps that have no need for such functionality.

[Assaf Raman]

...unfortunately I don't have an android device.

The emulation for Android is very good. Give it a try.

[calsmurf2904]

Basically,.. yea,... In a way that you create a libstdc++ for Android which is not a replacement but rather an expansion upon what Android offers in a way developers can easily link to and which additionally but most importantly does not impact the existing Android modules mitigating the fears of the Android dev's that the tinkering will make the platform unstable altogether for apps that have no need for such functionality.

Wait, so you mean making the standard libstdc++ minus the android libstdc++ functions as a seperate lib? So that we just link to it if we would compile Ogre?

...unfortunately I don't have an android device.

The emulation for Android is very good. Give it a try.

I did, it keeps showing Android in the screen but nothing else, currently trying another android API version (1.6, I tried it with 2.0 and 2.0.1). I think the target android versions for Ogre would be >= 2.0 since they contain the most significant changes to the rendering part.

Edit
This is what I get with the emulator:
http://img705.imageshack.us/img705/4628 ... torv16.png

[jacmoe]

He means: take the Android libstdc++ and extend it.
Like a filter.

[calsmurf2904]

Yes, I understand...But we could do that 2 ways:
1) Just edit the existing android libstdc++
or
2) Make a new lib called extended-libstdc++ (so kinda like a new dll on windows) and add the extra stuff there. I think liberator means this one.
If we choose for 2 any apps using the extra stuff should link to libstdc++ and extended-libstdc++.

I'm wondering though, when we use newlib we need to run it on the kernel side and replace the existing lib for it. This might be some issues though. I don't think its possible to just link it from an application (unless we could "emulate" the functions it calls by user side functions)

[liberator]

Yes, I understand...But we could do that 2 ways:
1) Just edit the existing android libstdc++
or
2) Make a new lib called extended-libstdc++ (so kinda like a new dll on windows) and add the extra stuff there. I think liberator means this one.
If we choose for 2 any apps using the extra stuff should link to libstdc++ and extended-libstdc++.

I indeed meant Nr2 with the sidenote that it depends on how you choose to expose the API that determines whether you need to link to libstdc++ and extended-libstdc++ or just to extended-libstdc++. The latter would be the case if you make the lib a pass-trough for all standard libstdc++ functionality to the Android libstdc++. It bloats the lib with extra exports but at least you would only need to link to 1 lib with extra options stemming from its role as a proxy such as compensating for unforeseen problems in the wrapper functions. Not sure which would be the best. Gut feeling wise I prefer the latter.

[calsmurf2904]

Plus this issue: (We might be able to do this though, not really sure....still trying to get the android emulator working :/)

I'm wondering though, when we use newlib we need to run it on the kernel side and replace the existing lib for it. This might be some issues though. I don't think its possible to just link it from an application (unless we could "emulate" the functions it calls by user side functions)

[calsmurf2904]

Seems like it does work, but really slow (it takes about 3 minutes to boot into Android on a Windows 7 x64 pc with an Intel Core2Duo 2,0 ghz processor)

[Assaf Raman]

A different approach that you can also look into is to compile the c++ to c.
http://www.edg.com/index.php?location=c_frontend

...Also included: a C-generating back end, which can be used to generate C code for C++ programs...

If it support exceptions - it may be a solution.

I didn't try it out and I don't know how good it does the job.

[calsmurf2904]

A GNU C and C++ compatibility mode, which provides the extensions supported by GCC (versions 3.2-4.3), along with various undocumented features and bugs. The compatibility is good enough that the front end can compile the Linux kernel and utilities.

That sounds like it supports exceptions, not sure how much this will work and if this will also for ARM. (Which is the main concern).

[Assaf Raman]

Here is one more c++ to c compiler.

[calsmurf2904]

Here is one more c++ to c compiler.

Thanks, that one costs money though. I'm currently trying the newlib way so that we actually have true C++ exception handling without needing to convert it to C. (Many people would want it this way anyway)

[Assaf Raman]

Sounds good.

[calsmurf2904]

Looking at it it actually seems that we have 3 options:
1) Replace full libc with newlib. (Which provides the additional functions needed such as exceptions).
2) Add exceptions to the Google Android libc. (This seems like a more better option since this could be applied as patch to their current libc.)
3) Create extended-libc (not libstdc++) and port over the full libstdc++ using the android libc+extended-libc.

I'm more in for option 2, newlib is good but it seems to much of an issue to get working.

[Assaf Raman]

2 seems great, but - is seems very hard, do you think you can handle it?

[calsmurf2904]

Not sure, haven't ever programmed on this level. (Kernel side). Perhaps someone could cooperate with me on doing this.

[Assaf Raman]

Try to find help on that google thread.

[Praetor]

If you add exception support to their lib do you think they will accept your patches and put it into official Android distros? The alternative is that we maintain a separate fork (which is certainly a big hassle).