abi x86 and arm64-v8a failed to build (link) in the example app
Closed this issue · 5 comments
In build.gradle: If I set
abiFilters 'armeabi-v7a'
the example app built.
If I set it to
abiFilters 'x86' or
abiFilters 'arm64-v8a'
The build fails with a line similar to
undefined reference to 'boost::system::detail::system_category_instance'.
I was doing this so I could run the sample on the Android emulator.
This issue:
boostorg/system#26 (comment)
indicates that it is a language feature problem. I rebuilt boost with
cxxstd=14
added to the run ./b2 call in build-boost.sh. This allowed it to link for all 4 abis.
It didn't look like you were keeping a user-config.jam that I could have put the change into. Maybe this should become the default in the shell script?
I can do a PR if you want it as a change to the script.
Your local.properties references a version of the NDK to use in your project.
Boost itself is also built with a specific version of the NDK.
These 2 versions should match (at least the major number ie 16, 17, 18 etc)
For me (current version of) Boost (1.68.0) builds fine with NDK 17c (arm64-v8a, armeabi-v7a, x86 and x86_64).
This was the current version of the NDK until some days ago.
So setting the NDK in your local.properties (of the sample app) to match should be fine.
However, building boost with the new NDK 18 causes problems. Your suggestion with cxxstd=14 doesn't seem to help. If you disagree please follow up.
If you are using the new (version 18) NDK in the sample app (Android Studio automatically prompts you to update) then you should be using a version of boost also built with this ndk. Its not surprising that you are getting link errors otherwise.
If you are able to build boost with NDK 18 then please let me know exactly how you managed.
Until the problem building boost with NDK 18 gets fixed then Im afraid your apps cant use NDK 18 with boost either
Thanks in Advance
Using NDK 17.2.4988734 on a mac, I get the build failure with Boost 1.68. This branch: https://github.com/bavery22/Boost-for-Android/tree/cxx14_boost168_issue_breaks_example fails to build for me (I changed gradle to have only the X86 ABI). I also did a PR with my cxxstd=14 change to build_boost.sh which allowed the example app to build and run on the X86 emulator.
Emulator : Pixel XL API 27 Android 8.1.0 (x86)
To replicate build failure, I
Clean Project
Make Project
Try removing the cppFlags "-std=c++14" from the app's build.gradle
That should do the trick. Can you please confirm?
Without the flags you passed b2, boost itself should build with the defaults for the compiler (version) being used.
In general both boost and the application should be built with the same language level ie c++14/11/98 etc. (Its not guaranteed to create a problem if these don't match (and for armeabi-v7a it seems it didn't) but its not safe at best). Thanks for pointing to this problem.
Id suggest commenting out the cppFlags "-std=c++14" from the app's build.gradle as the solution. Would you like to create a pull request for this?
I think in general, both boost and the sample app should build with the compilers default language level, and if one wants to override this one should do it in both the app and boost.
By the way c++ 14 will be the default for ndk 18 (support coming soon) which has clang 7
I cant find any official documentation on building boost with different language levels. If I add the flag you suggest at a different place eg
run ./b2 -d+2 -q -j$NUM_JOBS \
variant=release \
cxxstd=14 \
link=$LIB_LINKAGE \
runtime-link=shared \
then this also strangely gives link errors.
There's also the approach here.
Confirmed. Removing the cppFlags "-std=c++14" from the app's build.gradle allowed me to build and run it on an x86 emulator, on a mac host build system.
I agree that keeping both the sample app and boost to the compilers default language level makes sense. If someone needs to change it, I prefer your changing the flags approach anyway. I'll do a different PR for the app/build.gradle change.
Thanks!