GNOME Bugzilla – Bug 738928
android: Tutorials won't link with NDK-r10C
Last modified: 2014-11-01 15:34:23 UTC
The build works just fine with the same procedure with r9d (the default for in cerbero). This look like an recent incompatible change with our build system, or build system in tutorials (slomo branch). The error occur at linking: priv_gst_parse_yylex:lex.priv_gst_parse_yyl.c:1617 error: undefined reference to '__srget' _g_local_get_charset_alias:localcharset.c:158 error: undefined reference to '__srget' ...
Works for me with a clean build with r10c. My guess would be that the old ndk creates ABI incompatible binaries... would be good to check if the new ndk can build something that the old can consume.
Note that "works for me" here is ambiguous, since the report is about building an app from pre-built GStreamer 1.4.3 (built with r8) but with a local NDK that is r10c. What works for you is to build an app with r10c from a GStreamer build that is also using r10c. Thanks for testing that though. I would also be interested to know if mixing NDK could have other side effects. If it does, we probably need to document what NDK we have been using to produce the "official builds" and but that in the release notes.
It's supposed to be compatible, but for Android L Google also removed some other symbols... so I'm not surprised to see problems here. I would hope that something built with r10c also works with older versions.
Ok, then I'll test that later, and if fine the solution would be to build with newest NDK on next release.
Any news on this, Nicolas? I'm successfully using r10c for some things now... and the next releases are going to be built with that too. However we should report any incompatibilities to Google
So far, we confirmed 1 incompatibility: App built with r10c won't link against GStreamer built with r8c I think the other-way around (app built with older SDK against GStreamer built with newer SDK) isn't likely. I doubt compile time incompatibility is something Google really support, but do we have a contact that could clarify this ? I'll reproduce today and clarify what symbols are gone missing (or moved), and specially check if run-time could have been affected. If run-time is not affected, I doubt Google will consider the "incompatibility" valid. Might also be some link order issue on our side.
link order issue seems unlikely, it's something from libc :) If stuff built with an older NDK does not work with a newer NDK I would consider that a bug, and Google should too. There are many Android libraries out there, including proprietary ones, that are built with an older NDK and you don't really want everybody to provide a new release once there is a new NDK release. That's just unacceptable. For the other way around, using r10c binaries when building an app with an older NDK should also work... otherwise... see above. You would require all users of some binary released library to update the NDK every time.
Ok, it's all documented in the NDK changelog, so they intentionally broken the ABI. I don't think we can do anything about it, it's not our bug. https://developer.android.com/tools/sdk/ndk/index.html Removed the following symbols from all architectures: get_malloc_leak_info, free_malloc_leak_info, __srget, __swbuf, __srefill, __swsetup, __sdidinit, __sflags, __sfp, __sinit, __smakebuf, __sflush, __sread, __swrite, __sseek, __sclose, _fwalk, __sglue, __get_thread, __wait4, __futex_wake, __open, __get_tls, __getdents64, and dlmalloc. Removed the following functions from the 64-bit architectures: basename_r, dirname_r, __isthreaded, _flush_cache (mips64).