NDK platform static libraries need to be updated #272
Comments
Did you specify -D__ANDROID_API__=XX everywhere? From https://android.googlesource.com/platform/ndk.git/+/master/docs/UnifiedHeaders.md:
I've got the same error before. The reason is that in stdio.h, stderr have different names before and after API 23: #if __ANDROID_API__ >= 23
extern FILE* stdin __INTRODUCED_IN(23);
extern FILE* stdout __INTRODUCED_IN(23);
extern FILE* stderr __INTRODUCED_IN(23);
/* C99 and earlier plus current C++ standards say these must be macros. */
#define stdin stdin
#define stdout stdout
#define stderr stderr
#else
/* Before M the actual symbols for stdin and friends had different names. */
extern FILE __sF[] __REMOVED_IN(23);
#define stdin (&__sF[0])
#define stdout (&__sF[1])
#define stderr (&__sF[2])
#endif |
|
the point is, both |
|
I got it. I was using dynamic linking and libc.so have stdin/stdout/stderr symbols. Now I got linker failures for static linking, too. |
|
Was this resolved? I do not have linking issues with r14b, but r15c is failing to link stderr/stdout. Using make_standalone_toolchain.py --arch arm git clone https://chromium.googlesource.com/webm/libvpx create toolchain, add to pathCROSS=arm-linux-androideabi- ../libvpx/configure --target=armv7-android-gcc ivfdec.c.o:ivfdec.c:function file_is_ivf: error: undefined reference to 'stderr' |
|
no, no-one is working on updating the libc.a files yet. if you're linking statically, you'll want to target API < 23. iirc API 21 was the last libc.a update. |
|
make_standalone_toolchains.py defaults to API 14 for arm (21 for arm64): Using CC=clang CXX=clang++ the build completes successfully. Adding the api explicitly to the gcc build does work: so maybe the default API is not treated the same way between r14b and r15c? |
|
Might be related to a known issue [1]:
[1] https://android.googlesource.com/platform/ndk.git/+/master/docs/UnifiedHeaders.md |
|
If the libc.a won't be updated to match the unified header of stdio.h in r16, can we not simply "fix" the stdio.h so it define them correctly for the library? Otherwise, we'd have to either hack stdio.h, re-define the macros manually ourselves, or be forced to link against libc.so instead. |
|
i think you should just switch to clang now. (we're removing GCC in r18 anyway.) |
|
What does clang have to do with this? @nargus: no, we can't fix this for static libraries without breaking it for shared libraries, which are the average case by a very wide margin. |
|
(there are two bugs on this bug... it's half forked into "i'm getting the wrong results because i'm using GCC and it doesn't define |
|
Ah, I see. Yeah, the GCC problem is not something we have any intention of fixing. It's been marked as such in the changelog since r14. |
|
I'm actually already on Clang and have been trying to get my project compiled on the new r16 (beta-2). It's now almost working, excepted for the stdin/stdout linker errors mentioned above. |
|
Same here. I'm trying to compile libjpeg-turbo for armeabi-v7a and I also get the same type of "undefined reference to 'stderr'" errors. I'm using clang. |
|
Looks like it's not completely fixed for clang yet: https://android-review.googlesource.com/c/platform/bionic/+/522595 |
|
That's why the bug is still open. Targeting anything newer than android-21 for a static executable is not expected to work regardless of your compiler. |
|
@Adam-VisualVocal I managed to "fixed" the issue by using --include in my cmake flags with my custom header that undef & define the macros back to its pre-API 23. A bit hacky, but works just fine :) |
|
Why not just target android-21? |
|
Unfortunately, we actually need 24 :) |
|
If you're statically linking libc.a, you're not getting it. That's the root cause of this bug. |
- Compiling and linking ok - Supporting only 'armeabi' for now - Forcing APP_PLATFORM=android-23 to avoid NDK Bugs: android/ndk#272 android/ndk#410
|
This may end up happening for 17 beta 2, but I suspect this is more likely for r18. There's some work that needs to be done to make sure libandroid_support isn't used with libc.a since libc.a already contains everything in libandroid_support.a and will lead to multiple symbol definition errors. Unfortunately given the number of build systems we support I think this is likely to be a fair amount of work. |
|
@DanAlbert I believe you don't need all that many rebuilds of libc.a. You drop armeabi and both MIPS for r17, don't you? Then, you don't really care about the versions below API 21: whoever needs these can use the android-14 binary (they have already found the workarounds, anyway; unified headers hardly worsen the situation here). |
|
Our plan is to have only one libc.a for each arch going forward (always the latest). So far we haven't been able to come up with any reasons to use an old library. That still leaves the problem of not being able to link when using libandroid_support. |
|
Fixed in r17. |
If we're targeting a new enough platform version, we don't actually need to cover any gaps in libc for libc++ support. In those cases, save size in the APK by avoiding libandroid_support. This is also a requirement for static executables, since using libandroid_support with a modern libc.a will result in multiple symbol definition errors. Test: ndk/checkbuild.py && ndk/run_tests.py Bug: android/ndk#272 Change-Id: I4cb76272dc7271a02cba46d3cc20a369a16ff39d (cherry picked from commit db08a420b9b812321691180e97da1a3facc7391e)
We now have some static libraries from the platform rather than the old prebuilts in development/ndk. Install those when building a standalone standalone toolchain. Test: ./run_tests.py --filter standalone_toolchain* Test: Build static library, ls in sysroot/usr/lib Bug: android/ndk#272 Change-Id: I949cadbcd3ea50b58f46fb515ba8ca0684dbce31
If we're targeting a new enough platform version, we don't actually need to cover any gaps in libc for libc++ support. In those cases, save size in the APK by avoiding libandroid_support. This is also a requirement for static executables, since using libandroid_support with a modern libc.a will result in multiple symbol definition errors. Test: ./checkbuild.py && ./run_tests.py Bug: android/ndk#272 Change-Id: Iec548d7a75cc407d091b1a2bc632df68756c717d (cherry picked from commit cf5442c13a4cd0fe8b01e27de3850727007988f0)
We now have up to date static libraries coming from the platform as prebuilts. They exist in $NDK/sysroot/usr/lib/$TRIPLE, but for the time being we'll also install them to the old platforms directory while we transition the build systems to the new location. Test: ./checkbuild.py && ./run_tests.py Bug: android/ndk#272 Change-Id: I3159ee32d3d3b02bbe44d011494a018732391a49 (cherry picked from commit 65290c0584fcfe51c1e7cae30abf26be3e990a77)
Test: ndk/checkbuild.py && ndk/validate.py Bug: android/ndk#272 Bug: android/ndk#294 Change-Id: Iea240e8b2241576121db1acf3a1bd9cfe3426677
Attempt to fix "undefined reference to 'stdout'" by adding a __ANDROID_API__ definition equal to the Android API version for the toolchain. ref: android/ndk#272 (comment) Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Attempt to fix "undefined reference to 'stdout'" by adding a __ANDROID_API__ definition equal to the Android API version for the toolchain. ref: android/ndk#272 (comment) Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
GCC is going to be removed in newer NDKs. GCC has issues according to users: android/ndk#272 (comment) Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
* Upgrading is needed in order to fix the stupid situation we're in
with docker-tini:
* Needs to have API >= 23 for sigtimedwait
(termux#899)
* Needs to have API <= 21 for static linking
(android/ndk#272)
* The latter of the 2 above restrictions was removed in NDK r17, so
that's why we're upgrading.
* The other changes (removed headers and patches) are according to
Mr. Fornwall himself:
termux#1905
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
* Upgrading is needed in order to fix the stupid situation we're in
with docker-tini:
* Needs to have API >= 23 for sigtimedwait
(termux#899)
* Needs to have API <= 21 for static linking
(android/ndk#272)
* The latter of the 2 above restrictions was removed in NDK r17, so
that's why we're upgrading.
* The other changes (removed headers and patches) are according to
Mr. Fornwall himself:
termux#1905
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
* Upgrading is needed in order to fix the stupid situation we're in
with docker-tini:
* Needs to have API >= 23 for sigtimedwait
(termux#899)
* Needs to have API <= 21 for static linking
(android/ndk#272)
* The latter of the 2 above restrictions was removed in NDK r17, so
that's why we're upgrading.
* The other changes (removed headers and patches) are according to
Mr. Fornwall himself:
termux#1905
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
… having __sF symbol not found. It make it work for API 21 (tested on Android 5.1) Maybe android/ndk#272. But adding -lc is enough to have numpy not complaining about __sF missing anymore (stdout/stderr/stdin)
Test: build/soong/scripts/build-ndk-prebuilts.sh Bug: android/ndk#272 Change-Id: Icd3b737b443afa18a87558447808dceb2a401036
Test: build/soong/scripts/build-ndk-prebuilts.sh Bug: android/ndk#272 Change-Id: Ibb21d799fdcf230ed45db0b809e20dd86d2d8e52
Test: build/soong/scripts/build-ndk-prebuilts.sh Bug: android/ndk#272 Change-Id: Ibb21d799fdcf230ed45db0b809e20dd86d2d8e52
Test: build/soong/scripts/build-ndk-prebuilts.sh Bug: android/ndk#272 Change-Id: Ibb21d799fdcf230ed45db0b809e20dd86d2d8e52
looks like the libc.a files haven't changed since API level 21? (and before that, not since 9?)
hit while trying to build toybox with NDK r14beta1 using --unified-headers. we'd get references to stuff (even including stderr) that isn't in the libc.a file.
The text was updated successfully, but these errors were encountered: