Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to build without using standalone toolchain? #773

Closed
rcdailey opened this issue Aug 15, 2018 · 8 comments
Closed

How to build without using standalone toolchain? #773

rcdailey opened this issue Aug 15, 2018 · 8 comments
Assignees
Milestone

Comments

@rcdailey
Copy link

It's mentioned in the roadmap for NDK that r19 or r20 (I forget which one) will deprecate or remove standalone toolchains. However, I do not see a guide anywhere today that shows how to build libraries against the NDK toolchains without using the standalone toolchains. There's a very good writeup on how to use the toolchain, but not one for without that I could find.

Basically if I build the Boost library, I can probably point --sysroot to the sysroot directory at the root, but I'm not sure how to do things like specify the STL to use, or specify the minimum API level. Does such a guide already exist? And if not, could this task serve as a request for such a guide?

@enh enh self-assigned this Aug 15, 2018
@enh
Copy link
Contributor

enh commented Aug 15, 2018

the key point is "deprecate or remove standalone toolchains by making every toolchain a standalone toolchain". you shouldn't be doing any prep work yet, because there's no new thing to move to yet. right now, you're doing it right if you're using a standalone toolchain.

r18 will remove stlport and gnustl, so there will no longer be any need to specify an STL. (i'll update the docs to reflect that when r18 ships.)

the API level is the only thing that remains, and that will be part of the triple.

@enh
Copy link
Contributor

enh commented Aug 15, 2018

(i'll leave this open for now, since our wording has definitely caused some confusion.)

@rcdailey
Copy link
Author

Ah, ok I misunderstood. Thank you for clarifying. I thought that we were expected to somehow use the existing NDK structure as a replacement for standalone, but that's not the case.

@DanAlbert
Copy link
Member

FYI, I also have no plans of getting rid of the standalone toolchain script. The only difference there is that it will essentially just be an overly complicated cp.

@arturbac
Copy link

arturbac commented Aug 23, 2018

To build boost i use pure ndk with b2
jobs="-j8 --ignore-site-config"

./b2 $jobs toolset=clang-aarch64 target-os=android link=static runtime-link=static variant=release optimization=speed ..[other options].. install
same for armv7a ex toolset=clang-arm
(replace '<' and '>' without ' )
custom project-config.jam
clang : arm : clang++ :
'<'compileflags'>'--sysroot=/opt/android-ndk-r18-beta1/sysroot
'<'compileflags'>'-I/opt/android-ndk-r18-beta1/sysroot/usr/include
'<'compileflags'>'-I/opt/android-ndk-r18-beta1/sysroot/usr/include/arm-linux-androideabi
'<'compileflags'>'--target=armv7-none-linux-androideabi
'<'compileflags'>'-march=armv7-a
'<'compileflags'>'-marm
'<'compileflags'>'-fPIC
'<'compileflags'>'-fvisibility=hidden
'<'compileflags'>'-fvisibility-inlines-hidden
'<'compileflags'>'-ffunction-sections
'<'compileflags'>'-funwind-tables
'<'compileflags'>'-fintegrated-as
'<'compileflags'>'-stdlib=libc++
'<'compileflags'>'-I/opt/android-ndk-r18-beta1/sources/cxx-stl/llvm-libc++/include
'<'compileflags'>'-I/opt/android-ndk-r18-beta1/sources/android/support/include
'<'compileflags'>'-I/opt/android-ndk-r18-beta1/sources/cxx-stl/llvm-libc++abi/include
'<'cxxflags'>'-fvisibility=hidden
'<'cxxflags'>'-fvisibility-inlines-hidden
'<'cxxflags'>'-fexceptions
'<'cxxflags'>'-frtti
'<'cxxflags'>'-mfloat-abi=softfp
'<'cxxflags'>'-mfpu=vfpv3-d16
'<'cxxflags'>'-fPIC
'<'linkflags'>'-march=armv7-a
'<'linkflags'>'-marm
'<'linkflags'>'-mfloat-abi=softfp
'<'linkflags'>'-mfpu=vfpv3-d16
'<'linkflags'>'-fPIC
'<'linkflags'>'--sysroot=/opt/android-ndk-r18-beta1/sysroot/
'<'linkflags'>'-Wl,--fix-cortex-a8
'<'linkflags'>'-Wl,--exclude-libs,libc++abi.a
'<'linkflags'>'-Wl,--exclude-libs,libc++.a
'<'linkflags'>'-Wl,--exclude-libs,libc++_static.a
'<'linkflags'>'-Wl,--exclude-libs,libandroid_support.a
'<'linkflags'>'-Wl,-z,relro
'<'linkflags'>'-Wl,-z,now
'<'linkflags'>'--sysroot=/opt/android-ndk-r18-beta1/sysroot/
'<'linkflags'>'-L/opt/android-ndk-r18-beta1/sources/cxx-stl/llvm-libc++/libs/armeabi-v7a
'<'linkflags'>'/opt/android-ndk-r18-beta1/sources/cxx-stl/llvm-libc++/libs/armeabi-v7a/libc++abi.a
'<'linkflags'>'/opt/android-ndk-r18-beta1/sources/cxx-stl/llvm-libc++/libs/armeabi-v7a/libc++.a
'<'linkflags'>'/opt/android-ndk-r18-beta1/sources/cxx-stl/llvm-libc++/libs/armeabi-v7a/libc++_static.a
'<'linkflags'>'/opt/android-ndk-r18-beta1/sources/cxx-stl/llvm-libc++/libs/armeabi-v7a/libandroid_support.a
'<'linkflags'>'-L/opt/android-ndk-r18-beta1/platforms/android-16/arch-arm/usr/lib
;

using clang : aarch64 : clang++ :
'<'compileflags'>'--sysroot=/opt/android-ndk-r18-beta1/sysroot/
'<'compileflags'>'-I/opt/android-ndk-r18-beta1/sysroot/usr/include
'<'compileflags'>'-I/opt/android-ndk-r18-beta1/sysroot/usr/include/aarch64-linux-android
'<'compileflags'>'--target=aarch64-none-linux-android
'<'compileflags'>'-march=armv8-a
'<'compileflags'>'-fvisibility=hidden
'<'compileflags'>'-fvisibility-inlines-hidden
'<'compileflags'>'-fPIC
'<'compileflags'>'-fintegrated-as
'<'compileflags'>'-ffunction-sections
'<'compileflags'>'-funwind-tables
'<'compileflags'>'-stdlib=libc++
'<'compileflags'>'-I/opt/android-ndk-r18-beta1/sources/cxx-stl/llvm-libc++/include
'<'compileflags'>'-I/opt/android-ndk-r18-beta1/sources/android/support/include
'<'compileflags'>'-I/opt/android-ndk-r18-beta1/sources/cxx-stl/llvm-libc++abi/include
'<'cxxflags'>'-fvisibility=hidden
'<'cxxflags'>'-fvisibility-inlines-hidden
'<'cxxflags'>'-fexceptions
'<'cxxflags'>'-frtti
'<'cxxflags'>'-fPIC
'<'cxxflags'>'-stdlib=libc++
'<'cxxflags'>'-I/opt/android-ndk-r18-beta1/sources/cxx-stl/llvm-libc++/include
'<'cxxflags'>'-I/opt/android-ndk-r18-beta1/sources/android/support/include
'<'cxxflags'>'-I/opt/android-ndk-r18-beta1/sources/cxx-stl/llvm-libc++abi/include
'<'cxxflags'>'-I/opt/android-ndk-r18-beta1/platforms/android-21/arch-arm64/usr/include/aarch64-linux-android
'<'linkflags'>'-march=armv8-a
'<'linkflags'>'-Wl,--exclude-libs,libc++abi.a
'<'linkflags'>'-Wl,--exclude-libs,libc++.a
'<'linkflags'>'-Wl,--exclude-libs,libc++_static.a
'<'linkflags'>'-Wl,--exclude-libs,libandroid_support.a
'<'linkflags'>'-Wl,-z,relro
'<'linkflags'>'-Wl,-z,now
'<'linkflags'>'-fPIC
'<'linkflags'>'--sysroot=/opt/android-ndk-r18-beta1/sysroot/
'<'linkflags'>'-L/opt/android-ndk-r18-beta1/sources/cxx-stl/llvm-libc++/libs/arm64-v8a/
'<'linkflags'>'/opt/android-ndk-r18-beta1/sources/cxx-stl/llvm-libc++/libs/arm64-v8a/libc++abi.a
'<'linkflags'>'/opt/android-ndk-r18-beta1/sources/cxx-stl/llvm-libc++/libs/arm64-v8a/libc++.a
'<'linkflags'>'/opt/android-ndk-r18-beta1/sources/cxx-stl/llvm-libc++/libs/arm64-v8a/libc++_static.a
'<'linkflags'>'/opt/android-ndk-r18-beta1/sources/cxx-stl/llvm-libc++/libs/arm64-v8a/libandroid_support.a
'<'linkflags'>'-L/opt/android-ndk-r18-beta1/platforms/android-23/arch-arm64/usr/lib/
'<'linkflags'>'-stdlib=libc++
;`

@DanAlbert DanAlbert added this to the r19 milestone Oct 18, 2018
@DanAlbert
Copy link
Member

Dup of #780 (and #125) and which is fixed in r19.

Simplified by #812.

@markand
Copy link

markand commented Nov 7, 2018

Sorry to ask here, I also like standalone toolchains because they are just easier to use when building external libraries that are autotools based. Using them you don't have to pass dozens of parameters. So it is safe to continue relying on it for the future?

@enh
Copy link
Contributor

enh commented Nov 7, 2018

we're just making every toolchain a standalone toolchain.

r18 removed stlport and gnustl, so there's no need to specify an STL.

the API level is now part of the triple.

r19 moves most compiler/linker flags into the driver (the clang binary itself).

there are no plans to remove the standalone toolchain script. the only difference is that it will essentially just be an overly complicated cp.

standalone toolchains are not "going away" so much as "going everywhere".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants