Comments (18)
(unified headers bug: #120
NDK roadmap: https://android.googlesource.com/platform/ndk.git/+/master/docs/Roadmap.md)
from ndk.
That all makes sense. Thanks again for the explanation.
from ndk.
This makes it impossible to create a statically linked executable that uses libc++. (I realize this is not officially supported
Do our docs say that somewhere? There's no reason we shouldn't support that.
Is there any chance we could see this fixed for the next release?
It will take some rearranging at the very least (the problem here is actually libandroid_support.a
), but it might be doable.
from ndk.
Thanks for the reply, @DanAlbert!
Do our docs say that somewhere? There's no reason we shouldn't support that.
That is my misunderstanding. I assumed it wasn't supported because in AOSP, static executables are created by specifying LOCAL_FORCE_STATIC_EXECUTABLE := true
in Android.mk
, whereas in the NDK, we have to use LOCAL_LDFLAGS := -static
(which could be considered a workaround).
EDIT: Typo: should -> could
from ndk.
Nah, static executables definitely have their uses, so we should support them.
from ndk.
Sorry to keep punting this. Been working on some of the prerequisites for this but it's not going to make r13.
from ndk.
What are the unified headers I've seen mentioned a few times? Will libc++ be default in r14 already?
from ndk.
libandroid_support is going to be the focus of r15, so this will be fixed as part of that effort.
from ndk.
Hmm. I'm actually not sure there's anything that can be done about this. libandroid_support by design provides symbols to override libc, so we can't remove them or make them weak. I think the only option is telling the linker to allow multiple definitions when using libandroid_support (probably via libc++) for a static executable, but that's probably not something we should be doing by default.
from ndk.
@DanAlbert Thanks for the reply! I agree that a hack like that probably shouldn't be enabled by default. However, if I wanted to enable it for a specific project, is it as simple as adding some LDFLAGS?
EDIT: One other question: is libc++ shipped with the NDK the same as the AOSP version? If so, how are static executables, like /init
built?
from ndk.
However, if I wanted to enable it for a specific project, is it as simple as adding some LDFLAGS?
Should be as simple as LOCAL_LDFLAGS += -Wl,--allow-multiple-definition
.
EDIT: One other question: is libc++ shipped with the NDK the same as the AOSP version? If so, how are static executables, like /init built?
Kind of. The libraries themselves are very similar, but we don't use libandroid_support in AOSP. libandroid_support is the library the provides all the things libc++ needs that were missing from Android until recently (most of the missing pieces were added in L, but a recent libc++ update actually required more so I think you don't have everything you need until you're targeting android-o). Since in AOSP we can just fix bionic to have the missing pieces, we don't need libandroid_support. In the NDK, where you want to run on older devices instead of only the absolute newest (unreleased) OS, you need libandroid_support.
from ndk.
Should be as simple as
LOCAL_LDFLAGS += -Wl,--allow-multiple-definition
.
Thanks. This should be simple enough to add to my project.
Kind of. The libraries themselves are very similar, but we don't use libandroid_support in AOSP. libandroid_support is the library the provides all the things libc++ needs that were missing from Android until recently (most of the missing pieces were added in L, but a recent libc++ update actually required more so I think you don't have everything you need until you're targeting android-o). Since in AOSP we can just fix bionic to have the missing pieces, we don't need libandroid_support. In the NDK, where you want to run on older devices instead of only the absolute newest (unreleased) OS, you need libandroid_support.
That's very interesting. I'm curious as to why libc.a
couldn't include all the newest changes. Wouldn't the kernel version be the only limiting factor when running on older versions of Android (eg. for newer syscalls)? If I target the android-24 NDK platform, for example, and link against libc.a
and libc++.a
, why would libandroid_support be necessary?
from ndk.
That's very interesting. I'm curious as to why libc.a couldn't include all the newest changes.
It could and in fact should, but that's actually a different issue. I've been needing to find some time to fix the AOSP build system to actually package those artifacts so we can ship them in the NDK again (you'll notice that we haven't shipped one for any recent API levels). Once we have an up to date libc.a in the NDK, you'd be able to use that with libc++_static.a and avoid libandroid_support entirely (though telling ndk-build to do that isn't intuitive, it is possible, essentially APP_STL := none
and use LOCAL_STATIC_LIBRARIES
instead).
The kernel version might be an issue depending on what you're doing, but that won't be a build time issue. If something isn't available you'll get ENOSYS
, but that's something that could happen even on a bleeding edge device.
from ndk.
FYI, despite the previous wontfix this actually ended up getting fixed in r17. In r17 libandroid_support is not used when you're targeting android-21 and above, which is fine for static executables (aside from netd being broken, but that's the norm for static executables for every release except the same one they were built against).
from ndk.
@DanAlbert I may be misunderstanding how things are working, but it seems that even in r17, libc++.a
is unconditionally pulling in libandroid_support.a
. Is this intended?
[armeabi-v7a] cat libc++.a
INPUT(-lc++_static -lc++abi -landroid_support -lunwind -ldl -latomic)
from ndk.
That was unintentional: #672
ndk-build and android.toolchain.cmake
don't use the libc++.a
or libc++.so
linker scripts. They link in the actual libraries directly, and they omit libandroid_support.a
for 21 and up. In r17, the make_standalone_toolchain.py
script strips out -landroid_support
if the --api
option is 21 or up.
In r18, the two linker scripts in sources/cxx-stl/llvm-libc++/libs/ABI
are replaced by per-API linker scripts, so libc++.a.19
has -landroid_support
but libc++.a.21
doesn't.
from ndk.
@rprichard Thanks! That's exactly the info I was looking for.
Looks like I need to figure out why my CMake build is including libc++.a
instead of libc++_static.a
and libc++abi.a
.
from ndk.
Yep, my issue was completely my fault. I had a static library that provided a dummy dladdr()
function (required by libunwind on armeabi-v7a) since in older versions of the NDK, there wasn't a libdl.a
. I was adding it to CMAKE_CXX_STANDARD_LIBRARIES
with:
string(APPEND CMAKE_CXX_STANDARD_LIBRARIES " ${MBP_LIBCXX_HACK_PATH}")
Apparently, when I do this, the variable gets set to include libc++.a
and ignores the libc++_static.a
and libc++abi.a
that was in CMAKE_CXX_STANDARD_LIBRARIES_INIT
. Not sure what CMake magic did this.
Anyway, since r17 includes libdl.a
, I removed the hack and everything seems to be fine now.
from ndk.
Related Issues (20)
- [BUG] Clang++ Segmentation fault when building AOSP branch android-14.0.0_r35 HOT 3
- [Bug]: error: ran out of registers during register allocation HOT 17
- Android builds with unity fail: "Library\Bee\artifacts\Android" HOT 4
- [FR] push/pop required policies in cmake toolchain file HOT 16
- [DOC] Clarification on 16k page size support for x86_64 devices HOT 3
- [DOC] `system_fonts.h` HOT 7
- [Bug]: Lambda segfaults in Clang HOT 11
- [FR] Official NDK release for Linux arm64 HOT 1
- [Bug]: fatal error: error in backend: Cannot select: 0x10ba8ace0: nxv4f32 = BUILD_VECTOR 0x133163a90, 0x1330f4800, 0x133108d20, 0x1248b9e60 HOT 6
- [BUG] Compilation Error with std::execution in C++17 HOT 3
- [BUG] CLEAR_VARS does not clear LOCAL_STRIP_MODE variable HOT 2
- [Bug]: Android NDK r27 rc2 miscompiles code with inderect gotos HOT 13
- [Bug] NDK's openmp test crashing on x86 with latest LLVM update HOT 4
- Please provide maintainable list of NDK codename-revision pairs HOT 3
- [Bug]: clang compile with -D_FORTIFY_SOURCE=2 -Dstatic= cause undefined symbol: snprintf HOT 7
- [BUG] android-ndk-r26c use -pg ld.lld: error: undefined symbol: _mcount HOT 7
- [Bug]: Compiler Crash HOT 5
- [FR] support libclang? HOT 1
- [BUG] investigate odd find_package behavior HOT 3
- [BUG] NDK 27 no longer supports passing in `CMAKE_SYSTEM_PROCESSOR` to CMake to set the arch HOT 7
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ndk.