Support for Android

older
[wave] preprocessor directives in...

Vicente J. Botet Escriba

21 Jan 2014 21 Jan '14

6:28 p.m.

Hi, I see that there are some trouble with Boost and Android: https://svn.boost.org/trac/boost/ticket/9082 http://www.boost.org/development/tests/develop/developer/output/apolukhin-An... Could someone state what is the Boost approach to support Android? Should the user build with NDK r8e? Does bjam supports a specific android platform? Best, Vicente

Show replies by date

Antony Polukhin

21 Jan 21 Jan

7:21 p.m.

2014/1/21 Vicente J. Botet Escriba

...

Hi,

I see that there are some trouble with Boost and Android:

https://svn.boost.org/trac/boost/ticket/9082

http://www.boost.org/development/tests/develop/developer/output/apolukhin-An...

I'm the Android tests runner from the second link. Let me describe the situation with Android.

...

Could someone state what is the Boost approach to support Android?

As far as I know the Boost approach is to support as many platforms as possible.

...

Should the user build with NDK r8e?

Android NDK gives an ability to compile for different Android API. Android API is Linux kernel functions + libc functions + Java methods. So the comment to the ticket ( https://svn.boost.org/trac/boost/ticket/9082#comment:1) is absolutely right. User must compile for at least android-9 API. NDK versions mainly differ in bugfixes and support for new Android API levels. android-9 API is pretty old, so there must be no problems even with older NDKs.

...

Does bjam supports a specific android platform?

Yes and no. Static libraries can be easily build (just a correctly setupped user-config.jam required). To build dynamic libraries bjam must be updated (Android has no librt, librt is a part of libc in Android). Currently I'm fixing scripts that run tests on Android emulator. This is required for regression testing only, at work we successfully use Boost on Android for more than a year. All the major patches for Android were already applied to Boost libraries in last year. Scripts and user-config.jam for regression testings can be found here: https://github.com/apolukhin/regression_android Nearest plans (for a month or two): * finish the work with scripts * successfully run tests on Android * update the regression testing docs, adding a section about cross compiling and running tests on emulator/remote device * find someone who will agree to update bjam (there is a bunch of minor issues) -- Best regards, Antony Polukhin

Vicente J. Botet Escriba

7:58 p.m.

Le 21/01/14 20:21, Antony Polukhin a écrit :

...

2014/1/21 Vicente J. Botet Escriba

...
Hi,

I see that there are some trouble with Boost and Android:

https://svn.boost.org/trac/boost/ticket/9082

http://www.boost.org/development/tests/develop/developer/output/apolukhin-An...

I'm the Android tests runner from the second link. Let me describe the situation with Android. Hi Antony,

...
Could someone state what is the Boost approach to support Android?

As far as I know the Boost approach is to support as many platforms as possible. My concern was more how to support this platform. For the answer to the next question I suspect that Boost can support Android only if the user uses NDK.

...
Should the user build with NDK r8e?

Android NDK gives an ability to compile for different Android API. Android API is Linux kernel functions + libc functions + Java methods. So the comment to the ticket ( https://svn.boost.org/trac/boost/ticket/9082#comment:1) is absolutely right. User must compile for at least android-9 API.

NDK versions mainly differ in bugfixes and support for new Android API levels. android-9 API is pretty old, so there must be no problems even with older NDKs.

...
Does bjam supports a specific android platform?

Yes and no. Static libraries can be easily build (just a correctly setupped user-config.jam required). To build dynamic libraries bjam must be updated (Android has no librt, librt is a part of libc in Android).

Boost.Chrono has this on the buil <target-os>linux:<linkflags>"-lrt -lpthread" Is there a specific target for Android I can use?

...

Currently I'm fixing scripts that run tests on Android emulator. This is required for regression testing only, at work we successfully use Boost on Android for more than a year. All the major patches for Android were already applied to Boost libraries in last year. Scripts and user-config.jam for regression testings can be found here: https://github.com/apolukhin/regression_android

Would your scripts take care of -lrt? What about -lpthread?

...

Nearest plans (for a month or two): * finish the work with scripts * successfully run tests on Android * update the regression testing docs, adding a section about cross compiling and running tests on emulator/remote device * find someone who will agree to update bjam (there is a bunch of minor issues)

Have you requested the needed features already? Best, Vicente

Antony Polukhin

22 Jan 22 Jan

6:15 a.m.

2014/1/21 Vicente J. Botet Escriba

...

Le 21/01/14 20:21, Antony Polukhin a écrit :

2014/1/21 Vicente J. Botet Escriba

...
Hi,

...
I see that there are some trouble with Boost and Android:

https://svn.boost.org/trac/boost/ticket/9082

http://www.boost.org/development/tests/develop/ developer/output/apolukhin-Android-boost-bin-v2-libs- chrono-test-arithmetic_pass_h-test-gcc-androiddebug-debug.html

I'm the Android tests runner from the second link. Let me describe the

situation with Android.

Hi Antony,

...
Could someone state what is the Boost approach to support Android?

...
As far as I know the Boost approach is to support as many platforms as possible.

My concern was more how to support this platform. For the answer to the next question I suspect that Boost can support Android only if the user uses NDK.

NDK is required for build. Most users will need an Android SDK too, to be able to use the libraries in their projects on non rooted devices, test code on virtual devices and to communicate with Java.

...

Boost.Chrono has this on the buil

<target-os>linux:<linkflags>"-lrt -lpthread"

Is there a specific target for Android I can use?

No, there is no such target. I'm thinking of a more generic solution to this issue. For example Google can add empty librt.a and libpthread.a to NDK. This will fix a lot of build scripts all around the internet, not just the Boost's build.

...

Currently I'm fixing scripts that run tests on Android emulator. This is

...
required for regression testing only, at work we successfully use Boost on Android for more than a year. All the major patches for Android were already applied to Boost libraries in last year. Scripts and user-config.jam for regression testings can be found here: https://github.com/apolukhin/regression_android

Would your scripts take care of -lrt? What about -lpthread?

No. No. This must be fixed by bjam or Google (preferable).

...

Nearest plans (for a month or two):

...
* finish the work with scripts * successfully run tests on Android * update the regression testing docs, adding a section about cross compiling and running tests on emulator/remote device * find someone who will agree to update bjam (there is a bunch of minor issues)

Have you requested the needed features already?

I've mention the issues in this letter (it also contains some useful information about Android platform and tests): http://lists.boost.org/Archives/boost/2013/11/208820.php Since then run.py became broken on Windows (now it always complains "fatal error: boost/config/user.hpp: No such file or directory"), so now I'm making scripts for Linux while Windows is not fixed. Before requesting features, regression testing on Windows must be fixed and run-on-android scripts must be stabilized. -- Best regards, Antony Polukhin

Vladimir Prus

6:26 a.m.

On 22.01.2014 10:15, Antony Polukhin wrote:

...

...
...
Would your scripts take care of -lrt? What about -lpthread?

No. No. This must be fixed by bjam or Google (preferable).

Would the below patch, along with using target-os=android when building, do the trick? Thanks,

Antony Polukhin

7:04 a.m.

2014/1/22 Vladimir Prus

...

On 22.01.2014 10:15, Antony Polukhin wrote:

...
...
Would your scripts take care of -lrt?

...
What about -lpthread?

No. No. This must be fixed by bjam or Google (preferable).

Would the below patch, along with using target-os=android when building, do the trick?

Looks like it will do the trick! Thanks a lot! However this arise a question: Who is in charge of specifying platform specific thread libraries? Bjam or each library developer? For example Boost.Chrono has the following: ./chrono/build/Jamfile.v2: <target-os>freebsd:<linkflags>"-lrt" ./chrono/build/Jamfile.v2: <target-os>linux:<linkflags>"-lrt -lpthread" ./chrono/perf/Jamfile.v2: <target-os>freebsd:<linkflags>"-lrt" ./chrono/perf/Jamfile.v2: <target-os>linux:<linkflags>"-lrt" ./chrono/test/Jamfile.v2: <target-os>freebsd:<linkflags>"-lrt" ./chrono/test/Jamfile.v2: <target-os>linux:<linkflags>"-lrt -lpthread" While bjam has exactly the same rules: switch $(target) { case windows : option = -mthreads ; case cygwin : option = -mthreads ; case solaris : option = -pthreads ; libs = rt ; case beos : # No threading options. case *bsd : option = -pthread ; # There is no -lrt on BSD. case sgi : # gcc on IRIX does not support multi-threading. case darwin : # No threading options. case * : option = -pthread ; libs = rt ; } And why do these rules do not work: If I remove handwritten rules from one of the jamfiles, I'll get ../../../bin.v2/libs/variant/perf/move_perf.test/gcc-4.6/release/link-static/move_perf.o: In function `scope::~scope()': move_perf.cpp:(.text._ZN5scopeD2Ev[_ZN5scopeD5Ev]+0x1b): undefined reference to `clock_gettime' -- Best regards, Antony Polukhin

Vladimir Prus

7:26 a.m.

On 22.01.2014 11:04, Antony Polukhin wrote:

...

2014/1/22 Vladimir Prus

...
On 22.01.2014 10:15, Antony Polukhin wrote:

...
...
Would your scripts take care of -lrt?

...
What about -lpthread?

No. No. This must be fixed by bjam or Google (preferable).

Would the below patch, along with using target-os=android when building, do the trick?

Looks like it will do the trick! Thanks a lot!

However this arise a question: Who is in charge of specifying platform specific thread libraries? Bjam or each library developer?

It normally should be specified by Boost.Build.

...

For example Boost.Chrono has the following: ./chrono/build/Jamfile.v2: <target-os>freebsd:<linkflags>"-lrt" ./chrono/build/Jamfile.v2: <target-os>linux:<linkflags>"-lrt -lpthread" ./chrono/perf/Jamfile.v2: <target-os>freebsd:<linkflags>"-lrt" ./chrono/perf/Jamfile.v2: <target-os>linux:<linkflags>"-lrt" ./chrono/test/Jamfile.v2: <target-os>freebsd:<linkflags>"-lrt" ./chrono/test/Jamfile.v2: <target-os>linux:<linkflags>"-lrt -lpthread"

While bjam has exactly the same rules: switch $(target) { case windows : option = -mthreads ; case cygwin : option = -mthreads ; case solaris : option = -pthreads ; libs = rt ; case beos : # No threading options. case *bsd : option = -pthread ; # There is no -lrt on BSD. case sgi : # gcc on IRIX does not support multi-threading. case darwin : # No threading options. case * : option = -pthread ; libs = rt ; }

And why do these rules do not work: If I remove handwritten rules from one of the jamfiles, I'll get

../../../bin.v2/libs/variant/perf/move_perf.test/gcc-4.6/release/link-static/move_perf.o: In function `scope::~scope()': move_perf.cpp:(.text._ZN5scopeD2Ev[_ZN5scopeD5Ev]+0x1b): undefined reference to `clock_gettime'

That's because the above build is not threading=multi, it's just single threaded build. I think that the 'rt' library is not actually threading, it has some timer stuff, so if chrono needs to use such timer stuff specifically, there's nothing extremely wrong about specifying that separately. - Volodya

Antony Polukhin

7:29 a.m.

2014/1/22 Vladimir Prus

...

On 22.01.2014 11:04, Antony Polukhin wrote:

...
2014/1/22 Vladimir Prus

On 22.01.2014 10:15, Antony Polukhin wrote:

...
Would your scripts take care of -lrt?

...
...
...
What about -lpthread?

No. No. This must be fixed by bjam or Google (preferable).

Would the below patch, along with using target-os=android when building, do the trick?

Looks like it will do the trick! Thanks a lot!

However this arise a question: Who is in charge of specifying platform specific thread libraries? Bjam or each library developer?

It normally should be specified by Boost.Build.

...
For example Boost.Chrono has the following: ./chrono/build/Jamfile.v2: <target-os>freebsd:<linkflags>"-lrt" ./chrono/build/Jamfile.v2: <target-os>linux:<linkflags>"-lrt -lpthread" ./chrono/perf/Jamfile.v2: <target-os>freebsd:<linkflags>"-lrt" ./chrono/perf/Jamfile.v2: <target-os>linux:<linkflags>"-lrt" ./chrono/test/Jamfile.v2: <target-os>freebsd:<linkflags>"-lrt" ./chrono/test/Jamfile.v2: <target-os>linux:<linkflags>"-lrt -lpthread"

While bjam has exactly the same rules: switch $(target) { case windows : option = -mthreads ; case cygwin : option = -mthreads ; case solaris : option = -pthreads ; libs = rt ; case beos : # No threading options. case *bsd : option = -pthread ; # There is no -lrt on BSD. case sgi : # gcc on IRIX does not support multi-threading. case darwin : # No threading options. case * : option = -pthread ; libs = rt ; }

And why do these rules do not work: If I remove handwritten rules from one of the jamfiles, I'll get

../../../bin.v2/libs/variant/perf/move_perf.test/gcc-4.6/ release/link-static/move_perf.o: In function `scope::~scope()': move_perf.cpp:(.text._ZN5scopeD2Ev[_ZN5scopeD5Ev]+0x1b): undefined reference to `clock_gettime'

That's because the above build is not threading=multi, it's just single threaded build. I think that the 'rt' library is not actually threading, it has some timer stuff, so if chrono needs to use such timer stuff specifically, there's nothing extremely wrong about specifying that separately.

- Volodya

Great thanks for the explanations! Then please merge the proposed patch. -- Best regards, Antony Polukhin

Vladimir Prus

7:32 a.m.

On 22.01.2014 11:29, Antony Polukhin wrote:

...

...
...
../../../bin.v2/libs/variant/perf/move_perf.test/gcc-4.6/ release/link-static/move_perf.o: In function `scope::~scope()': move_perf.cpp:(.text._ZN5scopeD2Ev[_ZN5scopeD5Ev]+0x1b): undefined reference to `clock_gettime'

That's because the above build is not threading=multi, it's just single threaded build. I think that the 'rt' library is not actually threading, it has some timer stuff, so if chrono needs to use such timer stuff specifically, there's nothing extremely wrong about specifying that separately.

- Volodya

Great thanks for the explanations! Then please merge the proposed patch.

Pushed to develop: https://github.com/boostorg/build/commit/31cfa99489a835dfac59a1ca807ca9de9a1... Let me know whether it improves the situation in practice. Thanks, Volodya

Antony Polukhin

8:18 a.m.

2014/1/22 Vladimir Prus <...>

...

Pushed to develop:

https://github.com/boostorg/build/commit/ 31cfa99489a835dfac59a1ca807ca9de9a178b48

Let me know whether it improves the situation in practice.

There is build issue now: D:/testing_boost_android/tools_bb/src/tools\gcc.jam:1029: syntax error at keyword case D:/testing_boost_android/tools_bb/src/build\toolset.jam:41: in toolset.using ERROR: rule "gcc.init" unknown in module "toolset". Maybe a whitespace is missing in gcc.jam? -- Best regards, Antony Polukhin

Jürgen Hunold

9:58 a.m.

Hi Antony. On Wednesday, 22. January 2014 12:18:02 Antony Polukhin wrote:

...

2014/1/22 Vladimir Prus <...>

...

D:/testing_boost_android/tools_bb/src/tools\gcc.jam:1029: syntax error at keyword case D:/testing_boost_android/tools_bb/src/build\toolset.jam:41: in toolset.using ERROR: rule "gcc.init" unknown in module "toolset".

Maybe a whitespace is missing in gcc.jam?

Yes, I've rearranged the white space in https://github.com/boostorg/build/commit/854d98d92c91ebbee557172c3cdcceb6352... Please try again. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold@gmx.eu ! Germany

Vladimir Prus

10:35 a.m.

On 22.01.2014 13:58, Jürgen Hunold wrote:

...

Hi Antony.

On Wednesday, 22. January 2014 12:18:02 Antony Polukhin wrote:

...
2014/1/22 Vladimir Prus <...>

...
D:/testing_boost_android/tools_bb/src/tools\gcc.jam:1029: syntax error at keyword case D:/testing_boost_android/tools_bb/src/build\toolset.jam:41: in toolset.using ERROR: rule "gcc.init" unknown in module "toolset".

Maybe a whitespace is missing in gcc.jam?

Yes, I've rearranged the white space in https://github.com/boostorg/build/commit/854d98d92c91ebbee557172c3cdcceb6352...

Doh! And thanks! - Volodya

3945

Age (days ago)

3946

Last active (days ago)

List overview

Download

11 comments

4 participants

participants (4)

Antony Polukhin
Jürgen Hunold
Vicente J. Botet Escriba
Vladimir Prus