Building Android Against glibc

[JayBird]

Hi Folks,

I'm getting start with Android, so please forgive me if someone
already asked this question. I have some native code that I would
like to write a JNI interface for Dalvik. However, my C++ code uses
RTTI, exceptions, the math library, and maybe some or components not
supported by Bionic. I was wondering is it possible to build Android
against the GNU glibc for development? If so, how?


Thanks in advance,
Jaybird

[David Turner]

no, you can't, unless you provide your executable as a static executable, which makes it unusable from JNI.

[JayBird]

Hi David,

Thanks for the quick response. What are the major road block from
making this happen? Re-working our C++ code to build against the
Bionic library is a major undertaking to experiment with Android.
Depending on the amount of work involved, I'm wondering would it be
easier to modify the part(s) of Android that are in compatible with
GNU C/C++ library. Could you elaborate a little more on this topic?
If this topic is covered in some previous post you point me to it?


Thanks,
Jaybird

On Nov 13, 1:27 pm, "David Turner" <di...@android.com> wrote:
> no, you can't, unless you provide your executable as a static executable,
> which makes it unusable from JNI.
>

[David Turner]

There is absolutely zero chance that GLibc becomes part of the Android open-source platform for licensing reasons.
(same for uCLibc, KLibc, DietLibc and EGlibc by the way)

That doesn't mean that we are totally opposed to people providing patches that would allow to use the Android
sources with GLibc, but we are not going to support this effort (which means that if some of our changes break
a GLibc system, that will be *your* problem, patches welcome).

Also, we make absolutely no guarantee about the correct behaviour of a GLibc-based Android system,
*especially* with regards to security.

[Brian Swetland]

To expand on David's remarks a bit, bionic exists for two reasons:

- To provide a small embedded libc

- To meet the license goals of the core android platform, which are:
- GPL for the Linux kernel and drivers
- Apache2/BSD/MIT whenever possible for userspace

One of my hopes is that over time we can reduce the footprint of the
core platform (by a combination of putting various modules on a diet
and also making the core build more configurable so unneeded components
may be more easily omitted).

Brian

[David Turner <di...@android.com>]

[JayBird]

Thanks David and Brian for the clarification. I'm still in the
learning phase. Are there any other limitations with Bionic that I
should be aware of?


--- Jaybird

[David Turner]

yes, see the CAVEATS file in the bionic/libc directory. Essentially:

- no support for C++ exceptions
- no real support for wchar_t and locales
- no support for pthread cancellation (but you still have pthread_cleanup_push/pop though)

the above are not included for real specific reasons, and this is unlikely to change.
but we're open to add other missing features. They're not there because we didn't need them yet
and didn't have a good reason to throw what would be essentially "dead code" in the mix.

[koba]

Don't forget to read $(TOP)/bionic/libc/CAVEATS
It's important.

http://android.git.kernel.org/?p=platform/bionic.git;a=blob_plain;f=libc/CAVEATS;hb=HEAD

[Richard Lee]

Bionic seems to only have support for x86 and arm. Are there any
plans to add mips or powerpc to that?

[David Turner]

as usual patches are welcomed. However we would *largely* prefer to have the corresponding
hardware to test this thing on (or a build/test server somewhere accessible through ssh).
Otherwise it's sure to bit-rot pretty fast.

[Danfuzz]

On Nov 14, 9:35 am, Richard Lee <Richard.D....@gmail.com> wrote:
> Bionic seems to only have support for x86 and arm.  Are there any
> plans to add mips or powerpc to that?

Android development doesn't happen in a vacuum. If someone has a
compelling business case to support a new architecture, then it will
very likely end up getting developed, one way or another. However,
that development might end up being done by folks other than the ones
who did the existing work.

For example, you yourself could sponsor the ports to MIPS and PowerPC,
by hiring a couple folks and working with the current Android
developers to get the necessary patches into a good shape for
integration into the project.

As David implied, though, unless these ports become essential to the
project (which more-or-less leads to big companies being willing to
fund their ongoing development and maintenance), they could easily bit-
rot away without the continued involvement and investment of the
interested parties, such as yourself.

-dan