Re: [RFC][i*86]appropriate target triplet for Android on x86?

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Fri, 19 Mar 2010, Doug Kwan (Ãö®¶¼w) wrote:

> Hi,
> 
>     I would like to get some advice on handling Android for x86 in
> tool configurations.  Android is based on Linux but it is exactly the
> same, so some customizations are required.  There was a discussion
> among people working on Android and someone suggested using
> i*86-unknown-android.  My question is whether this is a good thing to
> do.  I would also like to hear from the maintainer of the i*86
> backend.  Eventually we would like to see x86 Android modifications to
> be pushed up-stream.

My inclination is that Android should use the same arrangements as the 
existing support I added for different C libraries under the Linux kernel.

*-*-linux-gnu* means a system defaulting to using the GNU C library.  
*-*-linux-uclibc* means a system defaulting to using the uClibc library.  
So *-*-linux-android* would mean a system defaulting to using Android's C 
library.  -mglibc selects a multilib based on the GNU C library in a 
toolchain defaulting to uClibc; -muclibc selects a multilib based on 
uClibc in a toolchain defaulting to the GNU C library.  So -mandroid would 
be added to these options, and *-*-linux* configurations could support 
three C libraries.  This means that configure tests in target libraries 
that care about which C library is in use cannot be based on the target 
triplet; they must check features or preprocessor macros (existing code in 
libstdc++-v3 checks __UCLIBC__, for example).

All the triplets above could have existing suffixes, so 
i686-pc-linux-android, arm-none-linux-uclibceabi, 
powerpc-none-linux-androidspe (for example) would be possible 
combinations.

The __linux__ preprocessor macro would be defined for all configurations 
using the Linux kernel.  __gnu_linux__ should only be defined for those 
using the GNU C library (it's defined at present for those using uClibc as 
well, but I think that's a bug).

-- 
Joseph S. Myers
joseph@codesourcery.com