public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] 回复:[PATCH v1] include/mk/env_post.mk: enable __ANDROID__ definition for Android build
Date: Fri, 12 Apr 2019 08:28:14 +0200	[thread overview]
Message-ID: <20190412062814.GA18106@dell5510> (raw)
In-Reply-To: <5bad3463-5c4f-2b70-6500-70d715fd3181@xiaopeng.com>

Hi Zhengwang,

> > > According to [1] android toolchain (I guess both AOSP and NDK toolchain) define
> > > __ANDROID__. Which is what I'd expect.
> > > Grepping aosp only dnsmasq and swiftshader use -D__ANDROID__ (these are from
> > > externals). -DANDROID is use more times (e.g. some drivers in hardware - ril,
> > > qcom, libsensors and wpa_supplicant).
> > >  From my point of view, instead of -D__ANDROID__ or -DANDROID I'd prefer to to have
> > > proper #ifdef HAVE_FOO guarders made by autotools checks. As android is not the
> > > only minor libc. But I understand it's not always possible and we already use
> > > some #ifdef __ANDROID__ in library sources and headers, so ack from myself to
> > > help compilation outside AOSP and without NDK.
> > Actually I was wrong. 1) I was using NDK toolchain. I'd expect it'd generate
> > __ANDROID__, but I don't see it in the output. 2) Building for android with
> > distro toolchain doesn't make sense as it wouldn't have Bionic.

> 1) Did you build outside AOSP? If so,  I think it is reasonable since
Yes, with android NDK (for Bionic and special toolchain tweeks).
Then I use ANDROID=1

> whatever __ANDROID__ or ANDROID are defined by Android build system instead
> of toolchain. I also tried to build the external/* thing and found ANDROID
> was actually generated. In my test, ANDROID seems to be the more suitable
> one, but in fact we can not build ltp inside AOSP because there is no
> Android.mk in ltp (please correct me if I am wrong...),  so ANDROID is
Yes, inside AOSP you need to use Android fork [1] which uses usual Android.bp.
Therefore AOSP does not use our build system.

> meaningless to us here. Actually, this is why I think this patch is still
> useful, since __ANDROID__ is enough to distinguish what to compile if
> ANDROID=1 is set with make.

> 2) In the case of cross-compilation, I think it still makes sense, since we
> can use the same toolchain, such as clang,  and build parameters (the
> specify the include headers and libs, etc) as AOSP. This is what I am doing
> now, you can see my steps I posted in my previous reply. But in this case,
> we need to obviously set -D__ANDROID__ in CFLAGS. After that , the process
> should be similar as we launch a build inside AOSP.
I don't know much about android toolchain, but IMHO there are some other tweaks
in their build system (to comply changes in Bionic), so not sure if it's even
possible to avoid using NDK for out-of-aosp tree. See also [2]. But that's a
question for for Android devs.

> Regards,

> Zhengwang

Kind regards,
Petr

[1] https://android.googlesource.com/platform/external/ltp/
[2] https://groups.google.com/forum/#!topic/android-ndk/cf9_f1SLXls

  reply	other threads:[~2019-04-12  6:28 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-09  4:05 [LTP] [PATCH v1] include/mk/env_post.mk: enable __ANDROID__ definition for Android build Zhengwang Ruan
2019-04-09 16:45 ` [LTP] 回复:[PATCH " =?unknown-8bit?b?6Ziu5q2j5pe6?=
2019-04-10 14:16   ` Petr Vorel
2019-04-11  3:38     ` =?unknown-8bit?b?6Ziu5q2j5pe6?=
2019-04-11 16:27     ` Sandeep Patil
2019-04-11 17:37       ` Petr Vorel
2019-04-11 23:40         ` Petr Vorel
2019-04-12  4:45           ` =?unknown-8bit?b?6Ziu5q2j5pe6?=
2019-04-12  6:28             ` Petr Vorel [this message]
2019-04-12 16:15               ` =?unknown-8bit?b?6Ziu5q2j5pe6?=
2019-04-12 19:48                 ` Sandeep Patil
2019-04-16 12:27                   ` =?unknown-8bit?b?6Ziu5q2j5pe6?=
2019-04-17 16:39                     ` Sandeep Patil
2019-04-17 17:06                       ` Petr Vorel
2019-04-19 15:49                         ` =?unknown-8bit?b?6Ziu5q2j5pe6?=
2019-04-21 22:10                           ` Petr Vorel
2019-04-23 17:28                             ` =?unknown-8bit?b?6Ziu5q2j5pe6?=
2019-04-23 20:38                               ` Petr Vorel
2019-04-12  3:09       ` =?unknown-8bit?b?6Ziu5q2j5pe6?=
2019-04-24  9:14 ` [LTP] [PATCH " Petr Vorel
2019-04-24 19:23   ` Steve Muckle
2019-04-24 20:19     ` Petr Vorel
2019-04-25  3:08     ` =?unknown-8bit?b?6Ziu5q2j5pe6?=

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190412062814.GA18106@dell5510 \
    --to=pvorel@suse.cz \
    --cc=ltp@lists.linux.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox