It's a security feature. It generally hardly adds any overhead since the detected size is always a compile-time constant and if it can't detect one at compile-time it doesn't use it. Generally only enabled when optimization is enabled since it depends on that to detect the sizes.
Conversation
That specific fortify function issomething I got them to add upstream but I'm pretty sure my patch got stalled for months and they rewrote it to the new Clang-based approach:
android.googlesource.com/platform/bioni
They left me as the author but I don't think I really wrote what they landed.
1
1
Don't really understand how you're having problems since you don't seem to be in the niche scenario where that off-by-one error in the compile-time version check would matter. I'm also curious if that has to do with the patch being delayed and missing a whole release. *shrug*
1
I vaguely remember being super frustrated with how long it took to land that little patch among other things and it was part of getting burnt out with trying to upstream things into LLVM, Linux and AOSP since I can't imagine landing actually complex stuff upstream.
1
So basically, the way Bionic is supposed to work is that it has proper version checks for all newly added stuff and has versioned symbol export lists for the NDK. It hides symbols for newer version for an app that's not supposed to see them. Presumably why the symbol isn't there.
1
As opposed to glibc where you have to build against the oldest glibc version you want to support, with Bionic, you can use the latest NDK and Bionic to build for an ancient release since they have these version checks. I guess it was screwed up for this specific symbol though.
1
I don't quite understand how you're actually hitting a problem with it but that's the general idea of how it's supposed to work.
I think what's probably actually happening is your build system is not passing the API level as it's supposed to when it's building these files.
1
The build system needs to be setting the minimum API level so that the code isn't built to use symbols introduced in newer versions. I don't think this actually has to do with that old minor SDK issue but rather this is the canary in the coal mine breaking from having that issue.
1
I'm upgrading NDK-- if it's ok I'd like to check back if I upgrade and it's still not working. (It is *super* interesting to me tho this problem was not present when I was building the project as Gradle invoking CMake, but when I build the project with pure CMake it appears!)
1
Make sure the build system is setting __ANDROID_API__ to your minSdkVersion i.e. -D__ANDROID_API__=21 for how you have it set up. I think that's probably your actual problem rather than an SDK / NDK bug now that I actually think about it more.
1
See developer.android.com/ndk/guides/sdk for more details. Maybe the build system is broken and setting __ANDROID_API__ to targetSdkVersion instead of minSdkVersion? That would cause it to use fortified sendto (API >= 26) but then at runtime the linker isn't going to make it available.
I think that's the actual problem and that actually entirely makes sense as an explanation. I can't really see how the problem could be anything else other than that, actually.
1
That makes sense, but that wouldn't explain why add_subdirectory was "passing" the correct variables when invoking add_subdirectory on ode (so appears to have loaded without problems) but not when invoking add_subdirectory on puredata (so having problems).
1
Show replies