[LTP] [PATCH v1] include/mk/env_post.mk: enable __ANDROID__ definition for Android build

[LTP] [PATCH v1] include/mk/env_post.mk: enable __ANDROID__ definition for Android build

[Zhengwang Ruan]

Enable the __ANDROID__ definition by default for Android build, otherwise we
should manually enable it by configure command.

Signed-off-by: Zhengwang Ruan <ruanzw@xiaopeng.com>
---
 include/mk/env_post.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/mk/env_post.mk b/include/mk/env_post.mk
index 913bdf5..7953e0a 100644
--- a/include/mk/env_post.mk
+++ b/include/mk/env_post.mk
@@ -44,7 +44,7 @@ endif
 ifeq ($(ANDROID),1)
 # There are many undeclared functions, it's best not to accidentally overlook
 # them.
-CFLAGS				+= -Werror-implicit-function-declaration
+CFLAGS				+= -Werror-implicit-function-declaration -D__ANDROID__
 
 LDFLAGS				+= -L$(top_builddir)/lib/android_libpthread
 LDFLAGS				+= -L$(top_builddir)/lib/android_librt
-- 
2.7.4

[LTP] 回复：[PATCH v1] include/mk/env_post.mk: enable __ANDROID__ definition for Android build

[=?unknown-8bit?b?6Ziu5q2j5pe6?=]

Could anyone help me to review this patch? This is useful to cross-compile ltp for Android without specifying '-D__ANDROID__' in configure step.

Thanks!
Zhengwang


------------------------------------------------------------------
发件人：Zhengwang Ruan <ruanzw@xiaopeng.com>
发送时间：2019年4月9日(星期二) 12:05
收件人：ltp <ltp@lists.linux.it>
抄　送：Zhengwang Ruan <ruanzw@xiaopeng.com>
主　题：[PATCH v1] include/mk/env_post.mk: enable __ANDROID__ definition for Android build

Enable the __ANDROID__ definition by default for Android build, otherwise we
should manually enable it by configure command.

Signed-off-by: Zhengwang Ruan <ruanzw@xiaopeng.com>
---
 include/mk/env_post.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/mk/env_post.mk b/include/mk/env_post.mk
index 913bdf5..7953e0a 100644
--- a/include/mk/env_post.mk
+++ b/include/mk/env_post.mk
@@ -44,7 +44,7 @@ endif
 ifeq ($(ANDROID),1)
 # There are many undeclared functions, it's best not to accidentally overlook
 # them.
-CFLAGS    += -Werror-implicit-function-declaration
+CFLAGS    += -Werror-implicit-function-declaration -D__ANDROID__

 LDFLAGS    += -L$(top_builddir)/lib/android_libpthread
 LDFLAGS    += -L$(top_builddir)/lib/android_librt
-- 
2.7.4

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20190410/8684835f/attachment-0001.html>

[LTP] 回复：[PATCH v1] include/mk/env_post.mk: enable __ANDROID__ definition for Android build

[Petr Vorel]

Hi Sandeep, Steve,

> Could anyone help me to review this patch? This is useful to cross-compile ltp for Android without specifying '-D__ANDROID__' in configure step.

> Thanks!
> Zhengwang


> ------------------------------------------------------------------
> 发件人：Zhengwang Ruan <ruanzw@xiaopeng.com>
> 发送时间：2019年4月9日(星期二) 12:05
> 收件人：ltp <ltp@lists.linux.it>
> 抄　送：Zhengwang Ruan <ruanzw@xiaopeng.com>
> 主　题：[PATCH v1] include/mk/env_post.mk: enable __ANDROID__ definition for Android build

> Enable the __ANDROID__ definition by default for Android build, otherwise we
> should manually enable it by configure command.

> Signed-off-by: Zhengwang Ruan <ruanzw@xiaopeng.com>
> ---
>  include/mk/env_post.mk | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

> diff --git a/include/mk/env_post.mk b/include/mk/env_post.mk
> index 913bdf5..7953e0a 100644
> --- a/include/mk/env_post.mk
> +++ b/include/mk/env_post.mk
> @@ -44,7 +44,7 @@ endif
>  ifeq ($(ANDROID),1)
>  # There are many undeclared functions, it's best not to accidentally overlook
>  # them.
> -CFLAGS    += -Werror-implicit-function-declaration
> +CFLAGS    += -Werror-implicit-function-declaration -D__ANDROID__
Would adding __ANDROID__ definition help building LTP with distro
cross-compiler? (i.e. no NDK, no inside AOSP tree)?
I guess so and therefore, I'd be for this change.
I see some projects added it as well (busybox [1] [2], dnsmasq [3]).
BTW: where is defined for AOSP and NDK?

BTW (@cyril): I guess -Werror-implicit-function-declaration is the code which
requires adding <string.h> and <strings.h> (see my fix 4053a2551 ("lib: Add
missing <string.h> and <strings.h> includes")), I'd be for either adding it to
for all or removing it.

>  LDFLAGS    += -L$(top_builddir)/lib/android_libpthread
>  LDFLAGS    += -L$(top_builddir)/lib/android_librt

Kind regards,
Petr

[1] https://git.busybox.net/busybox/tree/configs/android_defconfig
[2] https://git.busybox.net/busybox/tree/configs/android_ndk_defconfig
[3] http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob_plain;f=bld/Android.mk;hb=HEAD

[LTP] 回复：[PATCH v1] include/mk/env_post.mk: enable __ANDROID__ definition for Android build

[=?unknown-8bit?b?6Ziu5q2j5pe6?=]

Hi Petr,


-------- Original Message --------
From: Petr Vorel
Sent: Wed, 10 Apr 2019 16:16:15 +0200
To: Sandeep Patil, Steve Muckle
Cc: Ltp, Zhengwang Ruan, Cyril Hrubis
Subject: Re: [LTP] 回复：[PATCH v1] include/mk/env_post.mk : enable 
__ANDROID__ definition for Android build
> Hi Sandeep, Steve,
>
>> Could anyone help me to review this patch? This is useful to cross-compile ltp for Android without specifying '-D__ANDROID__' in configure step.
>> Thanks!
>> Zhengwang
>
>> ------------------------------------------------------------------
>> 发件人：Zhengwang Ruan <ruanzw@xiaopeng.com>
>> 发送时间：2019年4月9日(星期二) 12:05
>> 收件人：ltp <ltp@lists.linux.it>
>> 抄　送：Zhengwang Ruan <ruanzw@xiaopeng.com>
>> 主　题：[PATCH v1] include/mk/env_post.mk: enable __ANDROID__ definition for Android build
>> Enable the __ANDROID__ definition by default for Android build, otherwise we
>> should manually enable it by configure command.
>> Signed-off-by: Zhengwang Ruan <ruanzw@xiaopeng.com>
>> ---
>>   include/mk/env_post.mk | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>> diff --git a/include/mk/env_post.mk b/include/mk/env_post.mk
>> index 913bdf5..7953e0a 100644
>> --- a/include/mk/env_post.mk
>> +++ b/include/mk/env_post.mk
>> @@ -44,7 +44,7 @@ endif
>>   ifeq ($(ANDROID),1)
>>   # There are many undeclared functions, it's best not to accidentally overlook
>>   # them.
>> -CFLAGS    += -Werror-implicit-function-declaration
>> +CFLAGS    += -Werror-implicit-function-declaration -D__ANDROID__
> Would adding __ANDROID__ definition help building LTP with distro
> cross-compiler? (i.e. no NDK, no inside AOSP tree)?
> I guess so and therefore, I'd be for this change.
> I see some projects added it as well (busybox [1] [2], dnsmasq [3]).
> BTW: where is defined for AOSP and NDK?


I found that '-DANDROID' instead of '-D__ANDROID__' was passed while 
cross-compiling binaries in my AOSP project.


Thanks!

Zhengwang

>
> BTW (@cyril): I guess -Werror-implicit-function-declaration is the code which
> requires adding <string.h> and <strings.h> (see my fix 4053a2551 ("lib: Add
> missing <string.h> and <strings.h> includes")), I'd be for either adding it to
> for all or removing it.
>
>>   LDFLAGS    += -L$(top_builddir)/lib/android_libpthread
>>   LDFLAGS    += -L$(top_builddir)/lib/android_librt
> Kind regards,
> Petr
>
> [1] https://git.busybox.net/busybox/tree/configs/android_defconfig
> [2] https://git.busybox.net/busybox/tree/configs/android_ndk_defconfig
> [3] http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob_plain;f=bld/Android.mk;hb=HEAD
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20190411/ff848e3f/attachment.html>

[LTP] 回复：[PATCH v1] include/mk/env_post.mk: enable __ANDROID__ definition for Android build

[Sandeep Patil]

On Wed, Apr 10, 2019 at 04:16:15PM +0200, Petr Vorel wrote:
> Hi Sandeep, Steve,
> 
> > Could anyone help me to review this patch? This is useful to cross-compile ltp for Android without specifying '-D__ANDROID__' in configure step.
> 
> > Thanks!
> > Zhengwang
> 
> 
> > ------------------------------------------------------------------
> > 发件人：Zhengwang Ruan <ruanzw@xiaopeng.com>
> > 发送时间：2019年4月9日(星期二) 12:05
> > 收件人：ltp <ltp@lists.linux.it>
> > 抄　送：Zhengwang Ruan <ruanzw@xiaopeng.com>
> > 主　题：[PATCH v1] include/mk/env_post.mk: enable __ANDROID__ definition for Android build
> 
> > Enable the __ANDROID__ definition by default for Android build, otherwise we
> > should manually enable it by configure command.
> 
> > Signed-off-by: Zhengwang Ruan <ruanzw@xiaopeng.com>
> > ---
> >  include/mk/env_post.mk | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> > diff --git a/include/mk/env_post.mk b/include/mk/env_post.mk
> > index 913bdf5..7953e0a 100644
> > --- a/include/mk/env_post.mk
> > +++ b/include/mk/env_post.mk
> > @@ -44,7 +44,7 @@ endif
> >  ifeq ($(ANDROID),1)
> >  # There are many undeclared functions, it's best not to accidentally overlook
> >  # them.
> > -CFLAGS    += -Werror-implicit-function-declaration
> > +CFLAGS    += -Werror-implicit-function-declaration -D__ANDROID__
> Would adding __ANDROID__ definition help building LTP with distro
> cross-compiler? (i.e. no NDK, no inside AOSP tree)?
> I guess so and therefore, I'd be for this change.
> I see some projects added it as well (busybox [1] [2], dnsmasq [3]).
> BTW: where is defined for AOSP and NDK?

I think I've used __ANDROID__ and __BIONIC__ in the past for android-specific
things.  Honestly, I haven't tried to build for Android outside of AOSP tree
yet. I am happy to test this if you tell me how? (sorry for that.)

Steve will also be back by 4/15 and he would know this more than I do.
So,  Ideally, if we can wait for him it will be great. In the mean time, I
can test..

FWIW, I want to be able to do this as well. I know its a lot of pain to have
to checkout 100s of gigabytes of AOSP tree in order to build LTP for Android
right now. So, let me know how I can test and compare.

<snip>


- ssp

[LTP] 回复：[PATCH v1] include/mk/env_post.mk: enable __ANDROID__ definition for Android build

[Petr Vorel]

Hi Sandeep,

thanks a lot for your comments.
...
> > > +++ b/include/mk/env_post.mk
> > > @@ -44,7 +44,7 @@ endif
> > >  ifeq ($(ANDROID),1)
> > >  # There are many undeclared functions, it's best not to accidentally overlook
> > >  # them.
> > > -CFLAGS    += -Werror-implicit-function-declaration
> > > +CFLAGS    += -Werror-implicit-function-declaration -D__ANDROID__
> > Would adding __ANDROID__ definition help building LTP with distro
> > cross-compiler? (i.e. no NDK, no inside AOSP tree)?
> > I guess so and therefore, I'd be for this change.
> > I see some projects added it as well (busybox [1] [2], dnsmasq [3]).
> > BTW: where is defined for AOSP and NDK?

> I think I've used __ANDROID__ and __BIONIC__ in the past for android-specific
> things.  Honestly, I haven't tried to build for Android outside of AOSP tree
> yet. I am happy to test this if you tell me how? (sorry for that.)
Great, thanks a lot!

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.

Acked-by: Petr Vorel <pvorel@suse.cz>

> Steve will also be back by 4/15 and he would know this more than I do.
> So,  Ideally, if we can wait for him it will be great. In the mean time, I
> can test..
Sure, this can wait for him.

> FWIW, I want to be able to do this as well. I know its a lot of pain to have
> to checkout 100s of gigabytes of AOSP tree in order to build LTP for Android
> right now. So, let me know how I can test and compare.
Simple 'make ANDROID=1' will do the build ANDROID is for skipping some tests
which are not android ready (+ this patch). I guess without this you probably
also want to remove -Werror-implicit-function-declaration (I haven't pushed all
my fixes of missing <string.h> and <strings.h> as this is infinite work so far.

I have in my private todo list to write some doc about building LTP for Android.
But probably you, Android devs, are more appropriate people :).

> - ssp

Kind regards,
Petr

[1] https://groups.google.com/forum/#!topic/android-ndk/cf9_f1SLXls

[LTP] 回复：[PATCH v1] include/mk/env_post.mk: enable __ANDROID__ definition for Android build

[Petr Vorel]

Hi Sandeep,

> > > > -CFLAGS    += -Werror-implicit-function-declaration
> > > > +CFLAGS    += -Werror-implicit-function-declaration -D__ANDROID__
> > > Would adding __ANDROID__ definition help building LTP with distro
> > > cross-compiler? (i.e. no NDK, no inside AOSP tree)?
> > > I guess so and therefore, I'd be for this change.
> > > I see some projects added it as well (busybox [1] [2], dnsmasq [3]).
> > > BTW: where is defined for AOSP and NDK?

> > I think I've used __ANDROID__ and __BIONIC__ in the past for android-specific
> > things.  Honestly, I haven't tried to build for Android outside of AOSP tree
> > yet. I am happy to test this if you tell me how? (sorry for that.)
> Great, thanks a lot!

> 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.

Kind regards,
Petr

[LTP] 回复：[PATCH v1] include/mk/env_post.mk: enable __ANDROID__ definition for Android build

[=?unknown-8bit?b?6Ziu5q2j5pe6?=]

-------- Original Message --------
From: Sandeep Patil
Sent: Thu, 11 Apr 2019 09:27:24 -0700
To: Petr Vorel
Cc: Ltp
Subject: Re: [LTP] 回复：[PATCH v1] include/mk/env_post.mk: enable 
__ANDROID__ definition for Android b uild
> On Wed, Apr 10, 2019 at 04:16:15PM +0200, Petr Vorel wrote:
>> Hi Sandeep, Steve,
>>
>>> Could anyone help me to review this patch? This is useful to cross-compile ltp for Android without specifying '-D__ANDROID__' in configure step.
>>> Thanks!
>>> Zhengwang
>>
>>> ------------------------------------------------------------------
>>> 发件人：Zhengwang Ruan <ruanzw@xiaopeng.com>
>>> 发送时间：2019年4月9日(星期二) 12:05
>>> 收件人：ltp <ltp@lists.linux.it>
>>> 抄　送：Zhengwang Ruan <ruanzw@xiaopeng.com>
>>> 主　题：[PATCH v1] include/mk/env_post.mk: enable __ANDROID__ definition for Android build
>>> Enable the __ANDROID__ definition by default for Android build, otherwise we
>>> should manually enable it by configure command.
>>> Signed-off-by: Zhengwang Ruan <ruanzw@xiaopeng.com>
>>> ---
>>>   include/mk/env_post.mk | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>> diff --git a/include/mk/env_post.mk b/include/mk/env_post.mk
>>> index 913bdf5..7953e0a 100644
>>> --- a/include/mk/env_post.mk
>>> +++ b/include/mk/env_post.mk
>>> @@ -44,7 +44,7 @@ endif
>>>   ifeq ($(ANDROID),1)
>>>   # There are many undeclared functions, it's best not to accidentally overlook
>>>   # them.
>>> -CFLAGS    += -Werror-implicit-function-declaration
>>> +CFLAGS    += -Werror-implicit-function-declaration -D__ANDROID__
>> Would adding __ANDROID__ definition help building LTP with distro
>> cross-compiler? (i.e. no NDK, no inside AOSP tree)?
>> I guess so and therefore, I'd be for this change.
>> I see some projects added it as well (busybox [1] [2], dnsmasq [3]).
>> BTW: where is defined for AOSP and NDK?
> I think I've used __ANDROID__ and __BIONIC__ in the past for android-specific
> things.  Honestly, I haven't tried to build for Android outside of AOSP tree
> yet. I am happy to test this if you tell me how? (sorry for that.)

Hi Sandeep,


You can try the steps below to make a build outside AOSP. In my case, it 
works fine.

$ autoreconf --install

$ ./configure --prefix=/tmp/ltp 
CC=${BUILD_PROJ_DIR}/prebuilts/clang/host/linux-x86/clang-4691093/bin/clang 
AR=${BUILD_PROJ_DIR}/prebuilts/clang/host/linux-x86/clang-4691093/bin/llvm-ar 
CFLAGS="-I ${BUILD_PROJ_DIR}/libnativehelper/include_jni -I 
${BUILD_PROJ_DIR}/system/core/include -I 
${BUILD_PROJ_DIR}/system/media/audio/include -I 
${BUILD_PROJ_DIR}/hardware/libhardware/include -I 
${BUILD_PROJ_DIR}/hardware/libhardware_legacy/include -I 
${BUILD_PROJ_DIR}/hardware/ril/include -I 
${BUILD_PROJ_DIR}/libnativehelper/include -I 
${BUILD_PROJ_DIR}/frameworks/native/include -I 
${BUILD_PROJ_DIR}/frameworks/native/opengl/include -I 
${BUILD_PROJ_DIR}/frameworks/av/include -isystem 
${BUILD_PROJ_DIR}/out/target/product/${PRODUCT_NAME}/obj/include 
-isystem ${BUILD_PROJ_DIR}/bionic/libc/include -isystem 
${BUILD_PROJ_DIR}/bionic/libc/kernel/uapi -isystem 
${BUILD_PROJ_DIR}/bionic/libc/kernel/uapi/asm-arm64 -isystem 
${BUILD_PROJ_DIR}/bionic/libc/kernel/android/scsi -isystem 
${BUILD_PROJ_DIR}/bionic/libc/kernel/android/uapi -target 
aarch64-linux-android 
-B${BUILD_PROJ_DIR}/prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9/aarch64-linux-android/bin 
-pthread -nostdlib -D__ANDROID__" --host=aarch64-linux-gnu 
LDFLAGS="-nostdlib -Wl,-dynamic-linker,/system/bin/linker64 
-Wl,--gc-sections -Wl,-z,nocopyreloc 
-Wl,-rpath-link=${BUILD_PROJ_DIR}/out/target/product/${PRODUCT_NAME}/obj/lib 
${BUILD_PROJ_DIR}/out/target/product/${PRODUCT_NAME}/obj/lib/crtbegin_dynamic.o 
-Wl,--whole-archive  -Wl,--no-whole-archive 
${BUILD_PROJ_DIR}/out/target/product/${PRODUCT_NAME}/obj/STATIC_LIBRARIES/libclang_rt.ubsan_minimal-aarch64-android_intermediates/libclang_rt.ubsan_minimal-aarch64-android.a 
${BUILD_PROJ_DIR}/out/target/product/${PRODUCT_NAME}/obj/STATIC_LIBRARIES/libcompiler_rt-extras_intermediates/libcompiler_rt-extras.a 
${BUILD_PROJ_DIR}/out/target/product/${PRODUCT_NAME}/obj/STATIC_LIBRARIES/libatomic_intermediates/libatomic.a 
${BUILD_PROJ_DIR}/out/target/product/${PRODUCT_NAME}/obj/STATIC_LIBRARIES/libgcc_intermediates/libgcc.a 
-Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,--build-id=md5 
-Wl,--warn-shared-textrel -Wl,--fatal-warnings 
-Wl,--no-undefined-version -Wl,-m,aarch64_elf64_le_vec 
-Wl,--hash-style=gnu -fuse-ld=gold -Wl,--icf=safe 
-Wl,--exclude-libs,libclang_rt.ubsan_minimal-aarch64-android.a 
-Wl,--no-undefined 
-B${BUILD_PROJ_DIR}/prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9/aarch64-linux-android/bin 
-L${BUILD_PROJ_DIR}/out/target/product/${PRODUCT_NAME}/obj/lib -lc++ -lc 
-lm -ldl 
${BUILD_PROJ_DIR}/out/target/product/${PRODUCT_NAME}/obj/lib/crtend_android.o"

$ make ANDROID=1


BTW,  ${BUILD_PROJ_DIR} refers to the path of your AOSP project, and 
${PRODUCT_NAME} refers to the product nickname inside your organization. 
you need to export these two variables before launch the above configure.


But unfortunately, you will encounter other build errors, especially 
those caused by -Werror-implicit-function-declaration. But I think it 
should be enough to tell the deference between __ANDROID__ and ANDROID.


Good luck! :-)

Zhengwang

>
> Steve will also be back by 4/15 and he would know this more than I do.
> So,  Ideally, if we can wait for him it will be great. In the mean time, I
> can test..
>
> FWIW, I want to be able to do this as well. I know its a lot of pain to have
> to checkout 100s of gigabytes of AOSP tree in order to build LTP for Android
> right now. So, let me know how I can test and compare.
>
> <snip>
>
>
> - ssp
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20190412/ccb40a26/attachment.html>

[LTP] 回复：[PATCH v1] include/mk/env_post.mk: enable __ANDROID__ definition for Android build

[=?unknown-8bit?b?6Ziu5q2j5pe6?=]

  Hi Petr,


-------- Original Message --------
From: Petr Vorel
Sent: Fri, 12 Apr 2019 01:40:42 +0200
To: Sandeep Patil
Cc: Ltp
Subject: Re: [LTP] 回复：[PATCH v1] include/mk/env_post.mk: enable 
__ANDROID__ definition for Android b uild
> Hi Sandeep,
>
>>>>> -CFLAGS    += -Werror-implicit-function-declaration
>>>>> +CFLAGS    += -Werror-implicit-function-declaration -D__ANDROID__
>>>> Would adding __ANDROID__ definition help building LTP with distro
>>>> cross-compiler? (i.e. no NDK, no inside AOSP tree)?
>>>> I guess so and therefore, I'd be for this change.
>>>> I see some projects added it as well (busybox [1] [2], dnsmasq [3]).
>>>> BTW: where is defined for AOSP and NDK?
>>> I think I've used __ANDROID__ and __BIONIC__ in the past for android-specific
>>> things.  Honestly, I haven't tried to build for Android outside of AOSP tree
>>> yet. I am happy to test this if you tell me how? (sorry for that.)
>> Great, thanks a lot!
>> 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 
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 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.


Regards,

Zhengwang

>
> Kind regards,
> Petr
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20190412/ce8bc90a/attachment.html>

[LTP] 回复：[PATCH v1] include/mk/env_post.mk: enable __ANDROID__ definition for Android build

[Petr Vorel]

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

[LTP] 回复：[PATCH v1] include/mk/env_post.mk: enable __ANDROID__ definition for Android build

[=?unknown-8bit?b?6Ziu5q2j5pe6?=]

-------- Original Message --------
From: Petr Vorel
Sent: Fri, 12 Apr 2019 08:28:14 +0200
To: 阮正旺
Cc: Sandeep Patil, Ltp, Steve Muckle
Subject: Re: [LTP] 回复：[PATCH v1] include/mk/env_post.mk : enable 
__ANDROID__ definition for Android build
> 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.

According to also [2], the situation gets clear now. All android targets 
should get __ANDROID__ defined by the compiler, but ANDROID only means 
'this is AOSP' and is only for Windows targets. In our case, __ANDROID__ 
should be preferred.


Regards,

Zhengwang

>
>> Regards,
>> Zhengwang
> Kind regards,
> Petr
>
> [1] https://android.googlesource.com/platform/external/ltp/
> [2] https://groups.google.com/forum/#!topic/android-ndk/cf9_f1SLXls
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20190413/747d6cf9/attachment.html>

[LTP] 回复：[PATCH v1] include/mk/env_post.mk: enable __ANDROID__ definition for Android build

[Sandeep Patil]

On Sat, Apr 13, 2019 at 12:15:18AM +0800, 阮正旺 wrote:
> 
> -------- Original Message --------
> From: Petr Vorel
> Sent: Fri, 12 Apr 2019 08:28:14 +0200
> To: 阮正旺
> Cc: Sandeep Patil, Ltp, Steve Muckle
> Subject: Re: [LTP] 回复：[PATCH v1] include/mk/env_post.mk : enable
> __ANDROID__ definition for Android build
> > 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.
> 
> According to also [2], the situation gets clear now. All android targets
> should get __ANDROID__ defined by the compiler, but ANDROID only means 'this
> is AOSP' and is only for Windows targets. In our case, __ANDROID__ should be
> preferred.

Correct, and the build can still be make ANDROID=1 which translates to
-D__ANDROID__.

JFYI, there have been occasions when we changed something in bionic as a
result of an LTP tests, so those fixes will be missing for someone who is
using ndk for testing and building LTP.

That being said, thats a fairly small subset and is manageable. We can catch
those in reviews / patches very easily.

I like the idea of being able to build ouf-of-aosp, so I'm going to give this
a try now and will report.

- ssp
> 
> 
> Regards,
> 
> Zhengwang
> 
> > 
> > > Regards,
> > > Zhengwang
> > Kind regards,
> > Petr
> > 
> > [1] https://android.googlesource.com/platform/external/ltp/
> > [2] https://groups.google.com/forum/#!topic/android-ndk/cf9_f1SLXls

[LTP] 回复：[PATCH v1] include/mk/env_post.mk: enable __ANDROID__ definition for Android build

[=?unknown-8bit?b?6Ziu5q2j5pe6?=]

  Hi Sandeep,


-------- Original Message --------
From: Sandeep Patil
Sent: Fri, 12 Apr 2019 12:48:09 -0700
To: 阮正旺
Cc: Petr Vorel, Ltp, Steve Muckle
Subject: Re: [LTP] 回复：[PATCH v1] include/mk/env_post.mk : enable 
__ANDROID__ definition for Android build
> On Sat, Apr 13, 2019 at 12:15:18AM +0800, 阮正旺 wrote:
>> -------- Original Message --------
>> From: Petr Vorel
>> Sent: Fri, 12 Apr 2019 08:28:14 +0200
>> To: 阮正旺
>> Cc: Sandeep Patil, Ltp, Steve Muckle
>> Subject: Re: [LTP] 回复：[PATCH v1] include/mk/env_post.mk : enable
>> __ANDROID__ definition for Android build
>>> 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.
>> According to also [2], the situation gets clear now. All android targets
>> should get __ANDROID__ defined by the compiler, but ANDROID only means 'this
>> is AOSP' and is only for Windows targets. In our case, __ANDROID__ should be
>> preferred.
> Correct, and the build can still be make ANDROID=1 which translates to
> -D__ANDROID__.
>
> JFYI, there have been occasions when we changed something in bionic as a
> result of an LTP tests, so those fixes will be missing for someone who is
> using ndk for testing and building LTP.
>
> That being said, thats a fairly small subset and is manageable. We can catch
> those in reviews / patches very easily.
>
> I like the idea of being able to build ouf-of-aosp, so I'm going to give this
> a try now and will report.

Have you tried to build out-of-aosp? :-)


Regards,

Zhengwang

> - ssp
>>
>> Regards,
>>
>> Zhengwang
>>
>>>> Regards,
>>>> Zhengwang
>>> Kind regards,
>>> Petr
>>>
>>> [1] https://android.googlesource.com/platform/external/ltp/
>>> [2] https://groups.google.com/forum/#!topic/android-ndk/cf9_f1SLXls
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20190416/cb4979bb/attachment.html>

[LTP] 回复：[PATCH v1] include/mk/env_post.mk: enable __ANDROID__ definition for Android build

[Sandeep Patil]

On Tue, Apr 16, 2019 at 08:27:24PM +0800, 阮正旺 wrote:
>  Hi Sandeep,
> 
> 
> -------- Original Message --------
> From: Sandeep Patil
> Sent: Fri, 12 Apr 2019 12:48:09 -0700
> To: 阮正旺
> Cc: Petr Vorel, Ltp, Steve Muckle
> Subject: Re: [LTP] 回复：[PATCH v1] include/mk/env_post.mk : enable
> __ANDROID__ definition for Android build
> > On Sat, Apr 13, 2019 at 12:15:18AM +0800, 阮正旺 wrote:
> > > -------- Original Message --------
> > > From: Petr Vorel
> > > Sent: Fri, 12 Apr 2019 08:28:14 +0200
> > > To: 阮正旺
> > > Cc: Sandeep Patil, Ltp, Steve Muckle
> > > Subject: Re: [LTP] 回复：[PATCH v1] include/mk/env_post.mk : enable
> > > __ANDROID__ definition for Android build
> > > > 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.
> > > According to also [2], the situation gets clear now. All android targets
> > > should get __ANDROID__ defined by the compiler, but ANDROID only means 'this
> > > is AOSP' and is only for Windows targets. In our case, __ANDROID__ should be
> > > preferred.
> > Correct, and the build can still be make ANDROID=1 which translates to
> > -D__ANDROID__.
> > 
> > JFYI, there have been occasions when we changed something in bionic as a
> > result of an LTP tests, so those fixes will be missing for someone who is
> > using ndk for testing and building LTP.
> > 
> > That being said, thats a fairly small subset and is manageable. We can catch
> > those in reviews / patches very easily.
> > 
> > I like the idea of being able to build ouf-of-aosp, so I'm going to give this
> > a try now and will report.
> 
> Have you tried to build out-of-aosp? :-)

Yes, I did that now and ran into a build error with pread02 pasted at the
end of this email.

This was much easier than I thought and I think I can start sending trivial
fixes as I go. Here's what I did.

1. Download the ndk20 beta from - https://developer.android.com/ndk/downloads
2. Set up ndk toolchains for autoconf as shown in
   https://developer.android.com/ndk/guides/other_build_systems#autoconf
3. In LTP, do
   $ ./configure --host x86_64-linux-android --prefix=<preferred install location>
   $ make ANDROID=1

Please let me know if this doesn't sound right? It seems a lot easier than
the steps pasted earlier.

- ssp


======================

/usr/local/google/home/sspatil/bin/android-ndk-r20-beta2/toolchains/llvm/prebuilt/linux-x86_64/bin/x86_64-linux-android28-clang -g -O2 -g -O2 -fno-strict-aliasing -pipe -Wall -W -Wold-style-definition -Werror-implicit-function-declaration -D_FORTIFY_SOURCE=2 -I/usr/local/google/home/sspatil/dev/ssd2/ltp/testcases/kernel/syscalls/preadv -I/usr/local/google/home/sspatil/dev/ssd2/ltp/testcases/kernel/syscalls/preadv/../utils -I../../../../include -I../../../../include -I../../../../include/old/   -L../../../../lib -L../../../../lib/android_libpthread -L../../../../lib/android_librt  preadv02.c   -lltp -o preadv02
preadv02.c:89:7: error: implicit declaration of function 'preadv' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
        TEST(preadv(*tc->fd, tc->name, tc->count, tc->offset));
             ^
1 error generated.
<builtin>: recipe for target 'preadv02' failed
make[4]: *** [preadv02] Error 1
make[4]: Leaving directory '/usr/local/google/home/sspatil/dev/ssd2/ltp/testcases/kernel/syscalls/preadv'
../../../include/mk/generic_trunk_target.inc:93: recipe for target 'all' failed
make[3]: *** [all] Error 2
make[3]: Leaving directory '/usr/local/google/home/sspatil/dev/ssd2/ltp/testcases/kernel/syscalls'
../../include/mk/generic_trunk_target.inc:93: recipe for target 'all' failed
make[2]: *** [all] Error 2
make[2]: Leaving directory '/usr/local/google/home/sspatil/dev/ssd2/ltp/testcases/kernel'
../include/mk/generic_trunk_target.inc:93: recipe for target 'all' failed
make[1]: *** [all] Error 2
make[1]: Leaving directory '/usr/local/google/home/sspatil/dev/ssd2/ltp/testcases'
Makefile:111: recipe for target 'testcases-all' failed
make: *** [testcases-all] Error 2

[LTP] 回复：[PATCH v1] include/mk/env_post.mk: enable __ANDROID__ definition for Android build

[Petr Vorel]

Hi Sandeep,

> > Have you tried to build out-of-aosp? :-)

> Yes, I did that now and ran into a build error with pread02 pasted at the
> end of this email.

> This was much easier than I thought and I think I can start sending trivial
> fixes as I go. Here's what I did.

> 1. Download the ndk20 beta from - https://developer.android.com/ndk/downloads
> 2. Set up ndk toolchains for autoconf as shown in
>    https://developer.android.com/ndk/guides/other_build_systems#autoconf
Thanks for a hint. I was using standalone toolchain [1], created with NKD r19,
but see according a doc that it was deprecated even for r19.

[1] https://developer.android.com/ndk/guides/standalone_toolchain

> 3. In LTP, do
>    $ ./configure --host x86_64-linux-android --prefix=<preferred install location>
>    $ make ANDROID=1

I'm also passing these flags to CFLAGS, but it might not be necessary:
 --sysroot=${SYSROOT} -I${SYSROOT}/usr/include -I${ANDROID_PREFIX}/include

for arm host I use:
--host arm-linux-androideabi

and also define CROSS_COMPILE + other variables:
export CROSS_COMPILE=$TOOLCHAIN_ROOT/bin/arm-linux-androideabi-
export AR=${CROSS_COMPILE}ar
export AS=${CROSS_COMPILE}as
export NM=${CROSS_COMPILE}nm
export CC=${CROSS_COMPILE}gcc
export LD=${CROSS_COMPILE}ld
export RANLIB=${CROSS_COMPILE}ranlib

Only CROSS_COMPILE should be needed as, others are in
include/mk/config.mk.default, but my toolchain setup does not detect them
(include/mk/config.mk does not have cross-compile versions)

> Please let me know if this doesn't sound right? It seems a lot easier than
> the steps pasted earlier.

> - ssp


> ======================

> /usr/local/google/home/sspatil/bin/android-ndk-r20-beta2/toolchains/llvm/prebuilt/linux-x86_64/bin/x86_64-linux-android28-clang -g -O2 -g -O2 -fno-strict-aliasing -pipe -Wall -W -Wold-style-definition -Werror-implicit-function-declaration -D_FORTIFY_SOURCE=2 -I/usr/local/google/home/sspatil/dev/ssd2/ltp/testcases/kernel/syscalls/preadv -I/usr/local/google/home/sspatil/dev/ssd2/ltp/testcases/kernel/syscalls/preadv/../utils -I../../../../include -I../../../../include -I../../../../include/old/   -L../../../../lib -L../../../../lib/android_libpthread -L../../../../lib/android_librt  preadv02.c   -lltp -o preadv02
> preadv02.c:89:7: error: implicit declaration of function 'preadv' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
>         TEST(preadv(*tc->fd, tc->name, tc->count, tc->offset));
>              ^
I bump into the same problem

+ this one:
pwritev02.c:85:7: error: implicit declaration of function 'pwritev' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
        TEST(pwritev(*tc->fd, tc->name, tc->count, tc->offset));

So for the build is needed to comment out HAVE_PREADV and HAVE_PWRITEV
definitions in include/config.h.

I don't know why autotools fails preadv and pwritev detection with AC_CHECK_FUNCS.
I considered it as problem of my setup, but maybe it's an autotools bug.

> 1 error generated.
> <builtin>: recipe for target 'preadv02' failed
> make[4]: *** [preadv02] Error 1
> make[4]: Leaving directory '/usr/local/google/home/sspatil/dev/ssd2/ltp/testcases/kernel/syscalls/preadv'
> ../../../include/mk/generic_trunk_target.inc:93: recipe for target 'all' failed
> make[3]: *** [all] Error 2
> make[3]: Leaving directory '/usr/local/google/home/sspatil/dev/ssd2/ltp/testcases/kernel/syscalls'
> ../../include/mk/generic_trunk_target.inc:93: recipe for target 'all' failed
> make[2]: *** [all] Error 2
> make[2]: Leaving directory '/usr/local/google/home/sspatil/dev/ssd2/ltp/testcases/kernel'
> ../include/mk/generic_trunk_target.inc:93: recipe for target 'all' failed
> make[1]: *** [all] Error 2
> make[1]: Leaving directory '/usr/local/google/home/sspatil/dev/ssd2/ltp/testcases'
> Makefile:111: recipe for target 'testcases-all' failed
> make: *** [testcases-all] Error 2


Kind regards,
Petr

[LTP] 回复：[PATCH v1] include/mk/env_post.mk: enable __ANDROID__ definition for Android build

[=?unknown-8bit?b?6Ziu5q2j5pe6?=]

Hi Sandeep, Petr,


-------- Original Message --------
From: Petr Vorel
Sent: Wed, 17 Apr 2019 19:06:51 +0200
To: Sandeep Patil
Cc: Zhengwang Ruan, Ltp, Steve Muckle
Subject: Re: [LTP] 回复：[PATCH v1] include/mk/env_post.mk : enable 
__ANDROID__ definition for Android build
> Hi Sandeep,
>
>>> Have you tried to build out-of-aosp? :-)
>> Yes, I did that now and ran into a build error with pread02 pasted at the
>> end of this email.
>> This was much easier than I thought and I think I can start sending trivial
>> fixes as I go. Here's what I did.
>> 1. Download the ndk20 beta from - https://developer.android.com/ndk/downloads
>> 2. Set up ndk toolchains for autoconf as shown in
>>     https://developer.android.com/ndk/guides/other_build_systems#autoconf
> Thanks for a hint. I was using standalone toolchain [1], created with NKD r19,
> but see according a doc that it was deprecated even for r19.
>
> [1] https://developer.android.com/ndk/guides/standalone_toolchain
>
>> 3. In LTP, do
>>     $ ./configure --host x86_64-linux-android --prefix=<preferred install location>
>>     $ make ANDROID=1
> I'm also passing these flags to CFLAGS, but it might not be necessary:
>   --sysroot=${SYSROOT} -I${SYSROOT}/usr/include -I${ANDROID_PREFIX}/include
>
> for arm host I use:
> --host arm-linux-androideabi
>
> and also define CROSS_COMPILE + other variables:
> export CROSS_COMPILE=$TOOLCHAIN_ROOT/bin/arm-linux-androideabi-
> export AR=${CROSS_COMPILE}ar
> export AS=${CROSS_COMPILE}as
> export NM=${CROSS_COMPILE}nm
> export CC=${CROSS_COMPILE}gcc
> export LD=${CROSS_COMPILE}ld
> export RANLIB=${CROSS_COMPILE}ranlib
>
> Only CROSS_COMPILE should be needed as, others are in
> include/mk/config.mk.default, but my toolchain setup does not detect them
> (include/mk/config.mk does not have cross-compile versions)
>
>> Please let me know if this doesn't sound right? It seems a lot easier than
>> the steps pasted earlier.
>> - ssp
>
>> ======================
>> /usr/local/google/home/sspatil/bin/android-ndk-r20-beta2/toolchains/llvm/prebuilt/linux-x86_64/bin/x86_64-linux-android28-clang -g -O2 -g -O2 -fno-strict-aliasing -pipe -Wall -W -Wold-style-definition -Werror-implicit-function-declaration -D_FORTIFY_SOURCE=2 -I/usr/local/google/home/sspatil/dev/ssd2/ltp/testcases/kernel/syscalls/preadv -I/usr/local/google/home/sspatil/dev/ssd2/ltp/testcases/kernel/syscalls/preadv/../utils -I../../../../include -I../../../../include -I../../../../include/old/   -L../../../../lib -L../../../../lib/android_libpthread -L../../../../lib/android_librt  preadv02.c   -lltp -o preadv02
>> preadv02.c:89:7: error: implicit declaration of function 'preadv' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
>>          TEST(preadv(*tc->fd, tc->name, tc->count, tc->offset));
>>               ^
> I bump into the same problem
>
> + this one:
> pwritev02.c:85:7: error: implicit declaration of function 'pwritev' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
>          TEST(pwritev(*tc->fd, tc->name, tc->count, tc->offset));
>
> So for the build is needed to comment out HAVE_PREADV and HAVE_PWRITEV
> definitions in include/config.h.
>
> I don't know why autotools fails preadv and pwritev detection with AC_CHECK_FUNCS.
> I considered it as problem of my setup, but maybe it's an autotools bug.

I also encountered this issue, but I temporarily walked around it by 
applying the following patch.

==================

$ git diff testcases/
diff --git a/testcases/commands/ldd/datafiles/Makefile 
b/testcases/commands/ldd/datafiles/Makefile
index d8bcf5c..74fbe50 100644
--- a/testcases/commands/ldd/datafiles/Makefile
+++ b/testcases/commands/ldd/datafiles/Makefile
@@ -30,7 +30,7 @@ CLEAN_TARGETS         += *.obj $(LDD_SO_FILES)
         $(CC) $(CFLAGS) -shared -o $@ $^

  lddfile.out: main.o $(LDD_SO_FILES)
-       $(CC) $(CFLAGS) -O -o $@ $?
+       $(CC) $(CFLAGS) $(LDFLAGS) -O -o $@ $?

  INSTALL_DIR            := testcases/data/ldd01

diff --git a/testcases/kernel/syscalls/Makefile 
b/testcases/kernel/syscalls/Makefile
index 45a00cf..27c2e7a 100644
--- a/testcases/kernel/syscalls/Makefile
+++ b/testcases/kernel/syscalls/Makefile
@@ -43,6 +43,8 @@ FILTER_OUT_DIRS       += \
         sched_getaffinity sched_setaffinity sendmsg setgroups setns 
sighold \
         sigrelse sigsuspend sigtimedwait sigwait sigwaitinfo stime \
         setdomainname sethostname symlinkat ulimit ustat vfork vhangup 
vmsplice
+
+FILTER_OUT_DIRS += preadv pwritev
  endif

==========

Then I can accomplish compiling LTP with android-ndk-r19c, and my 
configure as below.

==============

$ export NDK_TOOL_DIR=/path/to/android-ndk-r19c

$ ./configure --prefix=/tmp/ltp 
CC=${NDK_TOOL_DIR}/toolchains/llvm/prebuilt/linux-x86_64/bin/clang 
AR=${NDK_TOOL_DIR}/toolchains/llvm/prebuilt/linux-x86_64/bin/llvm-ar 
CFLAGS="-isystem ${NDK_TOOL_DIR}/sysroot/usr/include -I 
/media/Workspace/Softwares/Linux/toolschain/ndk/android-ndk-r19c/sysroot/usr/include 
-I 
/media/Workspace/Softwares/Linux/toolschain/ndk/android-ndk-r19c/sysroot/usr/include/aarch64-linux-android 
-D__ANDROID__ -fmessage-length=0 -W -Wall -Wno-unused -Winit-self 
-Wpointer-arith -no-canonical-prefixes -DNDEBUG -UDEBUG -fno-exceptions 
-Wno-multichar -O2 -g -fno-strict-aliasing 
-fdebug-prefix-map=/proc/self/cwd= 
-D__compiler_offsetof=__builtin_offsetof -Werror=int-conversion 
-Wno-reserved-id-macro -Wno-format-pedantic 
-Wno-unused-command-line-argument -fcolor-diagnostics 
-Wno-expansion-to-defined -Wno-zero-as-null-pointer-constant 
-ffunction-sections -fdata-sections -fno-short-enums -funwind-tables 
-fstack-protector-strong -Wa,--noexecstack -D_FORTIFY_SOURCE=2 
-Wstrict-aliasing=2 -Werror=return-type -Werror=non-virtual-dtor 
-Werror=address -Werror=sequence-point -Werror=date-time 
-Werror=format-security -nostdlibinc -march=armv8-a  -target 
aarch64-linux-android 
-B${NDK_TOOL_DIR}/toolchains/llvm/prebuilt/linux-x86_64/bin -std=gnu99 
-Wall -fPIE -D_USING_LIBCXX -Werror=int-to-pointer-cast 
-Werror=pointer-to-int-cast -Werror=address-of-temporary 
-Werror=return-type -Wno-tautological-constant-compare 
-Wno-null-pointer-arithmetic -Wno-enum-compare -Wno-enum-compare-switch 
-MD -nostdlib -pthread" --host=aarch64-linux-gnu LDFLAGS="-nostdlib 
-Wl,-dynamic-linker,/system/bin/linker64 -Wl,--gc-sections 
-Wl,-z,nocopyreloc 
-Wl,-rpath-link=${BUILD_PROJ_DIR}/out/target/product/e28/obj/lib 
${NDK_TOOL_DIR}/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/lib/aarch64-linux-android/28/crtbegin_dynamic.o 
-Wl,--whole-archive  -Wl,--no-whole-archive 
${NDK_TOOL_DIR}/toolchains/llvm/prebuilt/linux-x86_64/lib64/clang/8.0.2/lib/linux/libclang_rt.ubsan_minimal-aarch64-android.a 
${NDK_TOOL_DIR}/sysroot/usr/lib/aarch64-linux-android/libcompiler_rt-extras.a 
${NDK_TOOL_DIR}/toolchains/llvm/prebuilt/linux-x86_64/aarch64-linux-android/lib64/libatomic.a 
${NDK_TOOL_DIR}/toolchains/llvm/prebuilt/linux-x86_64/lib/gcc/aarch64-linux-android/4.9.x/libgcc.a 
-Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,--build-id=md5 
-Wl,--warn-shared-textrel -Wl,--fatal-warnings 
-Wl,--no-undefined-version -Wl,-m,aarch64_elf64_le_vec 
-Wl,--hash-style=gnu -fuse-ld=gold -Wl,--icf=safe 
-Wl,--exclude-libs,libclang_rt.ubsan_minimal-aarch64-android.a 
-Wl,--no-undefined 
-B${NDK_TOOL_DIR}/toolchains/llvm/prebuilt/linux-x86_64/bin 
-L${NDK_TOOL_DIR}/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/lib/aarch64-linux-android/28 
-lc++ -lc -lm -ldl 
${NDK_TOOL_DIR}/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/lib/aarch64-linux-android/28/crtend_android.o 
-target aarch64-linux-android"

$ make ANDROID=1


Regards,

Zhengwang

>> 1 error generated.
>> <builtin>: recipe for target 'preadv02' failed
>> make[4]: *** [preadv02] Error 1
>> make[4]: Leaving directory '/usr/local/google/home/sspatil/dev/ssd2/ltp/testcases/kernel/syscalls/preadv'
>> ../../../include/mk/generic_trunk_target.inc:93: recipe for target 'all' failed
>> make[3]: *** [all] Error 2
>> make[3]: Leaving directory '/usr/local/google/home/sspatil/dev/ssd2/ltp/testcases/kernel/syscalls'
>> ../../include/mk/generic_trunk_target.inc:93: recipe for target 'all' failed
>> make[2]: *** [all] Error 2
>> make[2]: Leaving directory '/usr/local/google/home/sspatil/dev/ssd2/ltp/testcases/kernel'
>> ../include/mk/generic_trunk_target.inc:93: recipe for target 'all' failed
>> make[1]: *** [all] Error 2
>> make[1]: Leaving directory '/usr/local/google/home/sspatil/dev/ssd2/ltp/testcases'
>> Makefile:111: recipe for target 'testcases-all' failed
>> make: *** [testcases-all] Error 2
>
> Kind regards,
> Petr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20190419/91ba37d3/attachment.html>

[LTP] 回复：[PATCH v1] include/mk/env_post.mk: enable __ANDROID__ definition for Android build

[Petr Vorel]

Hi Sandeep, Zhengwang,

> > I don't know why autotools fails preadv and pwritev detection with AC_CHECK_FUNCS.
> > I considered it as problem of my setup, but maybe it's an autotools bug.

> I also encountered this issue, but I temporarily walked around it by
> applying the following patch.

> ==================

> $ git diff testcases/
> diff --git a/testcases/commands/ldd/datafiles/Makefile
> b/testcases/commands/ldd/datafiles/Makefile
> index d8bcf5c..74fbe50 100644
> --- a/testcases/commands/ldd/datafiles/Makefile
> +++ b/testcases/commands/ldd/datafiles/Makefile
> @@ -30,7 +30,7 @@ CLEAN_TARGETS         += *.obj $(LDD_SO_FILES)
>         $(CC) $(CFLAGS) -shared -o $@ $^

>  lddfile.out: main.o $(LDD_SO_FILES)
> -       $(CC) $(CFLAGS) -O -o $@ $?
> +       $(CC) $(CFLAGS) $(LDFLAGS) -O -o $@ $?
What is this change for?

>  INSTALL_DIR            := testcases/data/ldd01

> diff --git a/testcases/kernel/syscalls/Makefile
> b/testcases/kernel/syscalls/Makefile
> index 45a00cf..27c2e7a 100644
> --- a/testcases/kernel/syscalls/Makefile
> +++ b/testcases/kernel/syscalls/Makefile
> @@ -43,6 +43,8 @@ FILTER_OUT_DIRS       += \
>         sched_getaffinity sched_setaffinity sendmsg setgroups setns sighold
> \
>         sigrelse sigsuspend sigtimedwait sigwait sigwaitinfo stime \
>         setdomainname sethostname symlinkat ulimit ustat vfork vhangup
> vmsplice
> +
> +FILTER_OUT_DIRS += preadv pwritev
Yes, that fixes build. But manually disabling features in config.h enables these
tests to be build.

Kind regards,
Petr

[LTP] 回复：[PATCH v1] include/mk/env_post.mk: enable __ANDROID__ definition for Android build

[=?unknown-8bit?b?6Ziu5q2j5pe6?=]

Hi Petr,


-------- Original Message --------
From: Petr Vorel
Sent: Mon, 22 Apr 2019 00:10:30 +0200
To: Zhengwang Ruan
Cc: Sandeep Patil, Ltp, Steve Muckle
Subject: Re: [LTP] 回复：[PATCH v1] include/mk/env_post.mk : enable 
__ANDROID__ definition for Android build
> Hi Sandeep, Zhengwang,
>
>>> I don't know why autotools fails preadv and pwritev detection with AC_CHECK_FUNCS.
>>> I considered it as problem of my setup, but maybe it's an autotools bug.
>> I also encountered this issue, but I temporarily walked around it by
>> applying the following patch.
>> ==================
>> $ git diff testcases/
>> diff --git a/testcases/commands/ldd/datafiles/Makefile
>> b/testcases/commands/ldd/datafiles/Makefile
>> index d8bcf5c..74fbe50 100644
>> --- a/testcases/commands/ldd/datafiles/Makefile
>> +++ b/testcases/commands/ldd/datafiles/Makefile
>> @@ -30,7 +30,7 @@ CLEAN_TARGETS         += *.obj $(LDD_SO_FILES)
>>          $(CC) $(CFLAGS) -shared -o $@ $^
>>   lddfile.out: main.o $(LDD_SO_FILES)
>> -       $(CC) $(CFLAGS) -O -o $@ $?
>> +       $(CC) $(CFLAGS) $(LDFLAGS) -O -o $@ $?
> What is this change for?

This is a really long story. In my build, I need to use '-nostdlib  
/ndk/path/to/crtend_android.o /ndk/path/to/crtbegin_dynamic.o' as linker 
arguments to cross-compile, and I have to put these arguments into 
LDFLAGS since there were other errors occurred on linking *.o to 
executable if I put them into CFLAGS.

Right here, lddfile.out is an executable and obviously needed to be 
linked, therefore LDFLAGS must be required in my case.


Regards,

Zhengwang


>
>>   INSTALL_DIR            := testcases/data/ldd01
>> diff --git a/testcases/kernel/syscalls/Makefile
>> b/testcases/kernel/syscalls/Makefile
>> index 45a00cf..27c2e7a 100644
>> --- a/testcases/kernel/syscalls/Makefile
>> +++ b/testcases/kernel/syscalls/Makefile
>> @@ -43,6 +43,8 @@ FILTER_OUT_DIRS       += \
>>          sched_getaffinity sched_setaffinity sendmsg setgroups setns sighold
>> \
>>          sigrelse sigsuspend sigtimedwait sigwait sigwaitinfo stime \
>>          setdomainname sethostname symlinkat ulimit ustat vfork vhangup
>> vmsplice
>> +
>> +FILTER_OUT_DIRS += preadv pwritev
> Yes, that fixes build. But manually disabling features in config.h enables these
> tests to be build.
>
> Kind regards,
> Petr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20190424/187172f2/attachment.html>

[LTP] 回复：[PATCH v1] include/mk/env_post.mk: enable __ANDROID__ definition for Android build

[Petr Vorel]

Hi Zhengwang,


> -------- Original Message --------
> From: Petr Vorel
> Sent: Mon, 22 Apr 2019 00:10:30 +0200
> To: Zhengwang Ruan
> Cc: Sandeep Patil, Ltp, Steve Muckle
> Subject: Re: [LTP] 回复：[PATCH v1] include/mk/env_post.mk : enable
> __ANDROID__ definition for Android build
> > Hi Sandeep, Zhengwang,

> > > > I don't know why autotools fails preadv and pwritev detection with AC_CHECK_FUNCS.
> > > > I considered it as problem of my setup, but maybe it's an autotools bug.
> > > I also encountered this issue, but I temporarily walked around it by
> > > applying the following patch.
> > > ==================
> > > $ git diff testcases/
> > > diff --git a/testcases/commands/ldd/datafiles/Makefile
> > > b/testcases/commands/ldd/datafiles/Makefile
> > > index d8bcf5c..74fbe50 100644
> > > --- a/testcases/commands/ldd/datafiles/Makefile
> > > +++ b/testcases/commands/ldd/datafiles/Makefile
> > > @@ -30,7 +30,7 @@ CLEAN_TARGETS         += *.obj $(LDD_SO_FILES)
> > >          $(CC) $(CFLAGS) -shared -o $@ $^
> > >   lddfile.out: main.o $(LDD_SO_FILES)
> > > -       $(CC) $(CFLAGS) -O -o $@ $?
> > > +       $(CC) $(CFLAGS) $(LDFLAGS) -O -o $@ $?
> > What is this change for?

> This is a really long story. In my build, I need to use '-nostdlib 
> /ndk/path/to/crtend_android.o /ndk/path/to/crtbegin_dynamic.o' as linker
> arguments to cross-compile, and I have to put these arguments into LDFLAGS
> since there were other errors occurred on linking *.o to executable if I put
> them into CFLAGS.

> Right here, lddfile.out is an executable and obviously needed to be linked,
> therefore LDFLAGS must be required in my case.

Thanks for info. Feel free to send a patch with a long description.

Back to the patch: I'm willing to merge it, just wait if any from Sandeep or
Steve (or any other android developer) will ack it.


Kind regards,
Petr

[LTP] [PATCH v1] include/mk/env_post.mk: enable __ANDROID__ definition for Android build

[Petr Vorel]

Hi Steve, Sandeep,

> Enable the __ANDROID__ definition by default for Android build, otherwise we
> should manually enable it by configure command.

> Signed-off-by: Zhengwang Ruan <ruanzw@xiaopeng.com>
> ---
>  include/mk/env_post.mk | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

> diff --git a/include/mk/env_post.mk b/include/mk/env_post.mk
> index 913bdf5..7953e0a 100644
> --- a/include/mk/env_post.mk
> +++ b/include/mk/env_post.mk
> @@ -44,7 +44,7 @@ endif
>  ifeq ($(ANDROID),1)
>  # There are many undeclared functions, it's best not to accidentally overlook
>  # them.
> -CFLAGS				+= -Werror-implicit-function-declaration
> +CFLAGS				+= -Werror-implicit-function-declaration -D__ANDROID__

>  LDFLAGS				+= -L$(top_builddir)/lib/android_libpthread
>  LDFLAGS				+= -L$(top_builddir)/lib/android_librt

Please, when you have time, can you please have a look into this?

IMHO the question is whether code guarded by __ANDROID__ (lib/tst_kernel.c,
rt_tgsigqueueinfo01.c, etc.) works as expected in NDK build (as in aosp you use
definitions in Android.bp anyway).

According to [1] -D__ANDROID__ is defined by toolchain (I understand it by both
aosp build and builds using NDK), so it shouldn't be needed.

Not sure if it makes sense to build for android with non android toolchain (i.e.
no aosp nor NDK, use generic arm cross compile toolchain or standard gcc/clang
in case of intel platform). If yes, than this patch would be useful, as generic
toolchain obviously don't define __ANDROID__.

Kind regards,
Petr

[1] https://groups.google.com/forum/#!topic/android-ndk/cf9_f1SLXls

[LTP] [PATCH v1] include/mk/env_post.mk: enable __ANDROID__ definition for Android build

[Steve Muckle]

Hi Petr, Zhengwang,

On 4/24/19 2:14 AM, Petr Vorel wrote:
> Hi Steve, Sandeep,
> 
...
> 
> Please, when you have time, can you please have a look into this?
> 
> IMHO the question is whether code guarded by __ANDROID__ (lib/tst_kernel.c,
> rt_tgsigqueueinfo01.c, etc.) works as expected in NDK build (as in aosp you use
> definitions in Android.bp anyway).
> 
> According to [1] -D__ANDROID__ is defined by toolchain (I understand it by both
> aosp build and builds using NDK), so it shouldn't be needed.

Using Sandeep's instructions and with your latest merged fixes I was 
able to build unmodified upstream with the NDK. I just tried running one 
of the test binaries on my device to sanity check it.

I put in an #error if __ANDROID__ is defined and it does look to be set 
by the NDK compiler. FWIW I am using Android API level 26, the minimum 
which provides hasmntopt. This gets configured in the "Set up ndk 
toolchains for autoconf" step Sandeep mentioned by setting the CC and 
CXX env vars appropriately.

Zhengwang can you try the steps Sandeep mentioned (with the API level 
tweak I mentioned above)?

> Not sure if it makes sense to build for android with non android toolchain (i.e.
> no aosp nor NDK, use generic arm cross compile toolchain or standard gcc/clang
> in case of intel platform). If yes, than this patch would be useful, as generic
> toolchain obviously don't define __ANDROID__.

Zhengwang had said

 >  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.

but it's not clear to me since you need to have bionic around anyway, 
and at that point, why not just use the Android toolchain?


thanks,
Steve

[LTP] [PATCH v1] include/mk/env_post.mk: enable __ANDROID__ definition for Android build

[Petr Vorel]

Hi Steve, Zhengwang,

> Using Sandeep's instructions and with your latest merged fixes I was able to
> build unmodified upstream with the NDK. I just tried running one of the test
> binaries on my device to sanity check it.

> I put in an #error if __ANDROID__ is defined and it does look to be set by
> the NDK compiler. FWIW I am using Android API level 26, the minimum which
> provides hasmntopt. This gets configured in the "Set up ndk toolchains for
> autoconf" step Sandeep mentioned by setting the CC and CXX env vars
> appropriately.
Thanks for testing. IMHO this is a simple proof that this patch (-D__ANDROID__)
is not needed.

...
> >  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.

> but it's not clear to me since you need to have bionic around anyway, and at
> that point, why not just use the Android toolchain?
No, you're right, that does not make sense.


> thanks,
> Steve

Kind regards,
Petr

[LTP] [PATCH v1] include/mk/env_post.mk: enable __ANDROID__ definition for Android build

[=?unknown-8bit?b?6Ziu5q2j5pe6?=]

Hi Steve,


-------- Original Message --------
From: Steve Muckle
Sent: Wed, 24 Apr 2019 12:23:01 -0700
To: Petr Vorel, Zhengwang Ruan
Cc: Sandeep Patil, Ltp, Kernel-team
Subject: Re: [LTP] [PATCH v1] include/mk/env_post.mk: enable __ANDROID__ 
definition for Android build
> Hi Petr, Zhengwang,
>
> On 4/24/19 2:14 AM, Petr Vorel wrote:
>> Hi Steve, Sandeep,
>>
> ...
>>
>> Please, when you have time, can you please have a look into this?
>>
>> IMHO the question is whether code guarded by __ANDROID__ 
>> (lib/tst_kernel.c,
>> rt_tgsigqueueinfo01.c, etc.) works as expected in NDK build (as in 
>> aosp you use
>> definitions in Android.bp anyway).
>>
>> According to [1] -D__ANDROID__ is defined by toolchain (I understand 
>> it by both
>> aosp build and builds using NDK), so it shouldn't be needed.
>
> Using Sandeep's instructions and with your latest merged fixes I was 
> able to build unmodified upstream with the NDK. I just tried running 
> one of the test binaries on my device to sanity check it.
>
> I put in an #error if __ANDROID__ is defined and it does look to be 
> set by the NDK compiler. FWIW I am using Android API level 26, the 
> minimum which provides hasmntopt. This gets configured in the "Set up 
> ndk toolchains for autoconf" step Sandeep mentioned by setting the CC 
> and CXX env vars appropriately.
>
> Zhengwang can you try the steps Sandeep mentioned (with the API level 
> tweak I mentioned above)?

Yes, I tried the steps as Sandeep mentioned and also put an "#error" if 
__ANDROID__ was defined, it proves NDK has defined it.

Thanks you guys very much for letting me know this.  :-)


>
>> Not sure if it makes sense to build for android with non android 
>> toolchain (i.e.
>> no aosp nor NDK, use generic arm cross compile toolchain or standard 
>> gcc/clang
>> in case of intel platform). If yes, than this patch would be useful, 
>> as generic
>> toolchain obviously don't define __ANDROID__.
>
> Zhengwang had said
>
> >  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.
>
> but it's not clear to me since you need to have bionic around anyway, 
> and at that point, why not just use the Android toolchain?

Yes, NDK should always be the best in the situation of cross-compiling 
for android. Thanks again!

Regards,

Zhengwang

>
>
> thanks,
> Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20190425/7ef04acf/attachment-0001.html>