Update to ndk-r23 #7339
Update to ndk-r23 #7339
Conversation
|
Heh, looks like |
|
@buttaface I tried building rust with r23 and it failed with a similar error as for navi (and other rust packages) above |
|
That's a good sign for the compiler build, as it probably got farther? The question is where that link requirement is added, and whether we need to replace it or just remove it. I'll look. |
|
@buttaface oh, wait, it is an even more trivial error: Just need to patch it to use llvm-ar instead of aarch64-linux-android-ar I believe |
|
I don't see anything in our repo and NDK 23 has nothing that could even use libgcc, even the gold linker is gone with the binutils removal. clang has some code that adds libgcc automatically, but your paste above has the rust build passing that libgcc dependency to clang, so it's coming from some Rust crate dependency most likely. |
Grimler91
force-pushed
the
ndk-r23
branch
3 times, most recently
from
4a73982
to
745ab73
Compare
|
attr fails with: With verbose make we have Where we can see that it adds With r21 it works fine. Really weird, TERMUX_MAKE_PROCESSES=1 does not help, |
|
attr error fixed by using |
|
Except for the issues with rust packages (maybe we need to wait for the next rust release for that), we also have some golang packages that still have the same issue as we saw with r22: (for dns2tcp here). We should be able to patch it though |
|
The rust error should have been fixed in rust-lang/rust#85806, so looks like our issue is that it fails to find libunwind. We have it in |
Grimler91
force-pushed
the
ndk-r23
branch
3 times, most recently
from
4741206
to
e6209af
Compare
finagolfin
force-pushed
the
ndk-r23
branch
2 times, most recently
from
ff64e77
to
903b886
Compare
|
Rebased and cached NDK 23, so we're not downloading 3+ GB every time this pull is updated and run through the CI. |
|
I have a CI that cross-compiles the Swift stdlib for Android, here are the changes that I had to make to cross-compile the Swift 5.4 stdlib for Android with NDK 23, finagolfin/swift-android-sdk#14 (the Swift compiler is easy, since it's written in C++ nothing should break): What's really strange about this one is it's not reproducible with the upcoming Swift 5.5 branch or the development trunk branch of Swift. I patched that NDK header locally to remove that attribute for now,
I will update the Swift package separately once this pull is in. |
landfillbaby
force-pushed
the
ndk-r23
branch
from
d0c5b4b
to
ab93e49
Compare
|
that rebase just now reenabled bgrep since the issue is fixed in upstream gnulib and bgrep's bootstrap checks out the latest version |
|
Unfortunately rust 1.55 does not seem to seem to fix the build issue we have, so it needs more investigation |
|
Would it be possible for us to workaround the problem with a linker script named libgcc.a which is empty / does nothing? |
Package still fails to build though:
FAILED: build/obj/source_bee/subprocess_posix.obj
aarch64-linux-android-clang -MMD -MT build/obj/source_bee/subprocess_posix.obj -MF build/obj/source_bee/subprocess_posix.obj.d -std=c++17 -O2 -Wall -Werror -fvisibility=hidden -I3rd/bee.lua/bee/nonstd -I3rd/bee.lua -DBEE_INLINE -DNDEBUG -fstack-protector-strong -Oz -I/data/data/com.termux/files/usr/include -o build/obj/source_bee/subprocess_posix.obj -c 3rd/bee.lua/bee/subprocess/subprocess_posix.cpp
3rd/bee.lua/bee/subprocess/subprocess_posix.cpp:152:17: error: 'posix_spawnattr_init' is unavailable: introduced in Android 28
int r = posix_spawnattr_init(&spawnattr_);
^
/data/data/com.termux/files/usr/include/spawn.h:56:5: note: 'posix_spawnattr_init' has been explicitly marked unavailable here
int posix_spawnattr_init(posix_spawnattr_t* __attr) __INTRODUCED_IN(28);
^
…so indicate that this library has been backported to API 24
As we have seen [1], i686 seem to explicitly need -fPIC. Pass CPPFLAGS in more places when building aapt, to avoid an error like: ld: error: relocation R_386_PC32 cannot be used against symbol config_free; recompile with -fPIC >>> defined in /tmp/config_utils-70060d.o >>> referenced by config_utils.c >>> /tmp/config_utils-70060d.o:(config_free) [1] #7215 (comment)
As part of ndk-r23 upgrade.
Seems we need to explicitly pass -fPIC for all arches.
Includes fix for -fno-integrated-as flag, which is needed by libx265 build.
|
Roughly half of the packages touched in this PR has been uploaded now. The other half are still building (currently building node for all arches), or has build issues. I will merge this now, and then spend tomorrow fixing missing packages and issues. I have also disabled syncing of my mirror for now, so that old package versions will be available until all of this is ironed out. |
|
is it ok if i push a couple of package updates now, or should i wait until after the mass rebuild is finished? |
it's DT_AARCH64_BTI_PLT (0x70000001). in android 12 linker it's just ignored. aosp-mirror/platform_bionic@8d55d18 |
|
termux/termux-elf-cleaner@9c739ff |
| @@ -10,16 +9,11 @@ diff -uNr ./usr.old/include/stdio.h ./usr/include/stdio.h | |||
| + | |||
| #include <bits/seek_constants.h> | |||
|
|
|||
| -#if __ANDROID_API__ < __ANDROID_API_N__ | |||
| #include <bits/struct_file.h> | |||
| -#endif | |||
There was a problem hiding this comment.
This header defines FILE, rather than keeping it an opaque struct, but we're not including this header anymore, following the NDK. This causes problems if some package tries to take sizeof(FILE), as I ran into with lldb:
/home/builder/.termux-build/libllvm/src/lldb/include/lldb/Utility/ReproducerInstrumentation.h:645:58: error: invalid application of 'sizeof' to an incomplete type '__sFILE'
m_stream.write(reinterpret_cast<const char *>(&t), sizeof(T));
^~~~~~~~~
You can work around it by including <bits/struct_file.h> in any files that need FILE to be defined.
|
NDK 23 is a big jump to clang 12 from the clang 9 we were using in NDK 21. For arm, I hit an issue where it may have been omitting the frame pointer in optimized builds before, but isn't anymore. A file in This may be because of this clang commit, llvm/llvm-project@8eda716, though I think that new
You can check if the frame pointer is being omitted by passing |
|
NDK 23 enabled C++ The problem here is a C++ file includes a header that includes |
Rust still searches for libgcc even though [85806] replaces internal use with libunwind, especially now that the Android NDK (since r23-beta3) doesn't ship with any of gcc anymore. The apparent solution is to build your application with nightly and compile std locally (`-Zbuild-std`), but that is not desired for the majority of users. [7339] suggests to provide a local `libgcc.a` as linker script, which simply redirects linking to `libunwind` instead - and that has proven to work fine so far. Intead of shipping this file with the crate or writing it to an existing link-search directory on the system, we write it to a new directory that can be easily passed or removed to `rustc`, say in the event that a user switches to an older NDK and builds without cleaning. For this we need to switch from `cargo build` to `cargo rustc`, but the existing arguments and desired workflow remain identical. [85806]: rust-lang/rust#85806 [7339]: termux/termux-packages#7339 (comment)
…189) Rust still searches for libgcc even though [85806] replaces internal use with libunwind, especially now that the Android NDK (since r23-beta3) doesn't ship with any of gcc anymore. The apparent solution is to build your application with nightly and compile std locally (`-Zbuild-std`), but that is not desired for the majority of users. [7339] suggests to provide a local `libgcc.a` as linker script, which simply redirects linking to `libunwind` instead - and that has proven to work fine so far. Intead of shipping this file with the crate or writing it to an existing link-search directory on the system, we write it to a new directory that can be easily passed or removed to `rustc`, say in the event that a user switches to an older NDK and builds without cleaning. For this we need to switch from `cargo build` to `cargo rustc`, but the existing arguments and desired workflow remain identical. [85806]: rust-lang/rust#85806 [7339]: termux/termux-packages#7339 (comment)
Here we go again.
rust packages fails with
ld: error: unable to find library -lgccWhen they try to link we get something like (example here for navi):
Broken up into lines we have
linker command
If I remove the
-lgccflags at the end there it works fine. Might be rust that adds it, and might be a linker flag we can pass to cargo to fix it.