NDK r11 undefined reference

[SimonMarquis]

Since NDK r11, bcopy is no longer defined in libc and triggers an error during linkage of libusrsctp for instance:
error: undefined reference to 'bcopy'

Application.mk:

APP_STL := c++_static
APP_OPTIM := release
APP_ABI := armeabi-v7a x86
APP_PLATFORM := android-14
NDK_TOOLCHAIN_VERSION := clang

Android.mk

LOCAL_CFLAGS            +=  -g
LOCAL_STATIC_LIBRARIES := libusrsctp
LOCAL_LDLIBS            := -lm -llog -landroid -lz
LOCAL_ARM_MODE          := arm
LOCAL_CPPFLAGS          += -std=c++11
include $(BUILD_SHARED_LIBRARY)
$(call import-module,android/cpufeatures)

Is this issue related to #1 ?

[DanAlbert]

Is libusrsctp something that you're building yourself, or a prebuilt library you're including? My test using everything but libusrsctp from your example works fine (my source file was a use of bcopy), so I'm guessing it's a prebuilt library.

[SimonMarquis]

It's indeed a prebuilt library (built from source before this step)

[DanAlbert]

Is it something that can be rebuilt with r11? That would solve the problem.

I don't know enough about the NDK ecosystem to know how widespread this kind of thing might be. How common is it to use prebuilt static libraries? (note that if it was a shared libusrsctp, it would actually link and load just fine)

[joakim-noah]

I'll note that libusrsctp is open-source, so it can certainly be recompiled. That doesn't preclude the question of closed static libraries though.

[DanAlbert]

Ack. We'd trimmed down the NDK stub libraries to match the current state of the headers (cases like bcopy are now just a macro instead of a real function). As it turns out that breaks ABI compatibility with static libraries...

We'll have to add back a bunch of those symbols, since having those gone doesn't help anyone (the symbols that are actually private implementation details will remain hidden, but bcopy and the like are perfectly reasonable).

[SimonMarquis]

I re-built it with latest NDK r11 without any issue 👍
I'm using static library because of how the current build process is done throughout our internal projects.

@DanAlbert you said bcopy is now a macro, can you tell me into what it results? (a private bcopy implementation or memmove?)
Thanks

[DanAlbert]

#define bcopy(b1, b2, len) (void)(__builtin_memmove((b2), (b1), (len)))

(I checked to be sure, and it is correctly defined as such across every API level, so no surprises there.)

[SimonMarquis]

Awsome!
I've read that bcopy was not standard and somewhat slow compared to memmove.
Thanks again for the quick support.

[DanAlbert]

Glad to hear it.

As far as adding back the symbols so we keep compatibility between r10 and r11 static libraries, I'm going to hold off to see if we get more reports of this. Compatibility for static libraries is something that is fairly fragile anyway (might even break compiler to compiler), so I'm leaning toward believing this isn't the norm.

If more reports come in though, then it will be clear that I was wrong and we'll get it fixed :)