Generally speaking, we try hard to maintain binary compatibility for all NDK-generated code, and this looks like a packaging error.
One big change that happened for NDK r7 is that we no longer put copies of the original system libraries in the NDK, to be used at link time.
Instead, the link-time libraries are "empty shells" that only export functions and variables. They are auto-generated when building the NDK from symbol files that explicitely list which functions/variables to export. It looks like the __atomic_xxx functions were omitted from some of these platform symbol files for some reason. I'll look into it.
Now, the case of the __atomic_xxx functions is a bit specific. As already outlined
in a previous post in this forum, applications should _not_ link against them, because they run the risk of not working properly on some multi-core devices. The alternative is to use the GCC atomic intrinsics functions.
NDK r7b (temporary name) will include a new version of <sys/atomics.h> that declares each of these functions as static inlines that use the GCC intrinsics (it's already on the AOSP servers, and you can find it attached to the post linked above too). This will allow you to simply rebuild your unmodified code and have something that is guaranteed to work correctly everywhere.
We also fixed the implementation of the functions to provide full memory barriers for the next release of the Android platform, to ensure that any unmodified binary will work properly if loaded on devices that support it. However, it will take time before this one is released and widely used, so in the meantime, rebuilding your machine code is the best option.
It also means that the __atomic_xxxx function symbols will be *removed* from the link-time libc.so in the next NDK release. This, with the updated <sys/atomics.h> header, will ensure that you cannot possibly generate machine code that link against the problematic functions in any way. But this is the exception, not the norm. It will *not* be removed from the platform's libc.so though, to ensure that any existing machine code that link against it will continue to load, and work on single-core devices, and even some multi-core ones.
(all this is already documented in ndk/docs/ANDROID-ATOMICS.html on the AOSP server).
Hope this helps
- David
Cheers,
BogDan.
--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.