bump(libllvm/flang): 20.1.8 to 21.1.3 #26521
Conversation
sorry if you already are working on it and know what to do, but in case you need help, when I look at the code related to this error, I could suggest changing the block if (TC.getTriple().isAndroid()) {
CmdArgs.push_back("-l:libandroid-complex-math.a");
}into if (getTriple().isAndroid()) {
CmdArgs.push_back("-l:libandroid-complex-math.a");
}because sorry if I overexplained this too much, maybe it is not a difficult problem for you to solve on your own. |
|
Fixed the issue and updated: thanks for looking into it, but I had simply moved that patch so it stayed in the method it was in, without checking if it still needed that qualifier. |
|
Alright, libllvm builds fine across all arches: download the CI-generated zip file, test it out and let us know if you see any problems. Flang has some build failure and if you look at the patch changes I had to make, it uses a new flang runtime directory that may require further changes to be built and installed. @licy183 or @robertkirkman, let me know if either of you want to handle that, as I am unfamiliar with flang, can just disable that update otherwise. I am going to refresh the files installed next and update the |
|
I will try to fix |
|
I can confirm that the change licy183 made is sufficient to build and at the moment, there is a severe error in The only distro currently listed by Repology as having started the update to LLVM 21 is Alpine Linux Edge, https://repology.org/project/llvm/versions and sure enough, when I took a look into Alpine Linux's WIP CI workflows, the only other place on the internet where the error https://gitlab.alpinelinux.org/alpine/aports/-/jobs/2006152/raw We could try to help Alpine Linux create a workaround for this error that is acceptable for both of our projects, or we could also potentially try my first idea for what the simplest workaround would be, which is to try reverting the problematic PR in |
|
I've found a workaround that seems correct - the required changes are not yet present in any stable release of Everything seems to work fine for me locally after doing that, so I can add my local changes into the PR for bumping |
|
I can confirm the current rust package can be rebuild to work with LLVM 21 without extra patches. |
|
@licy183, can you try out the flang package you just built and let us know if it is working well? |
|
No. It doesn't work properly because |
|
I started also trying to help to fix I tried this so far: @@ -78,6 +76,21 @@ termux_step_post_configure() {
}
termux_step_post_make_install() {
+ termux_setup_flang
+ # attempt to build libflang_rt.runtime.a
+ mkdir -p "$TERMUX_PKG_BUILDDIR/flang-rt"
+ cmake -S "$TERMUX_PKG_SRCDIR/runtimes" \
+ -B "$TERMUX_PKG_BUILDDIR/flang-rt" \
+ -GNinja \
+ -DLLVM_DIR=$TERMUX_PREFIX/lib/cmake/llvm \
+ -DCLANG_DIR=$TERMUX_PREFIX/lib/cmake/clang \
+ -DDLLVM_BINARY_DIR="$(dirname $(dirname $(command -v "$FC")))" \
+ -DCMAKE_Fortran_COMPILER="$(command -v "$FC")" \
+ -DCMAKE_Fortran_COMPILER_WORKS=yes \
+ -DLLVM_ENABLE_RUNTIMES=flang-rt
+
+ cmake --build "$TERMUX_PKG_BUILDDIR/flang-rt" --parallel $TERMUX_PKG_MAKE_PROCESSES
+
# Copy module source files
mkdir -p $TERMUX_PREFIX/opt/flang/{include,module}
cp -f $TERMUX_PKG_SRCDIR/flang/module/* $TERMUX_PREFIX/opt/flang/module/and unfortunately, this happens for me currently: I think that a large part of the problem (at least with my attempt) may be that an I have been trying to follow the directions given by this documentation, which has a worrying passage https://github.com/llvm/llvm-project/blob/main/flang-rt/README.md
That is what makes me think that maybe it will be necessary to somehow implement a As a status update, I have now managed to successfully use the This is not a complete solution yet because it is an on-device build and not a cross-compilation, but I hope that showing this can possibly help slightly with the eventual development of a successful cross-compilation of the same thing. successful on-device build and use of a `libflang_rt.runtime.a` with `flang` version 21# install all the current artifacts which are downloadable from this PR
apt reinstall ./libllvm_21.1.1_aarch64.deb \
./flang_21.1.1_aarch64.deb \
./clang_21.1.1_aarch64.deb \
./libcompiler-rt_21.1.1_aarch64.deb \
./llvm-tools_21.1.1_aarch64.deb \
./mlir_21.1.1_aarch64.deb \
./llvm_21.1.1_aarch64.deb
# get llvm source code at the correct version
wget https://github.com/llvm/llvm-project/releases/download/llvmorg-21.1.1/llvm-project-21.1.1.src.tar.xz
tar xf llvm-project-21.1.1.src.tar.xz
cd llvm-project-21.1.1.src/
git init && git add . && git commit -m "tmp"
# apply the regular needed Flang-for-Android patches copied from the termux package
git apply -v << 'EOF'
diff --git a/flang-rt/lib/quadmath/complex-math.h b/flang-rt/lib/quadmath/complex-math.h
index b76bf0373..ff1125869 100644
--- a/flang-rt/lib/quadmath/complex-math.h
+++ b/flang-rt/lib/quadmath/complex-math.h
@@ -34,6 +34,23 @@
#elif HAS_LDBL128
/* Use 'long double' versions of libm functions. */
#include <complex.h>
+#if defined(__ANDROID__) && __ANDROID_API__ < 26
+long double complex cacosl (long double complex);
+long double complex cacoshl(long double complex);
+long double complex casinl (long double complex);
+long double complex casinhl(long double complex);
+long double complex catanl (long double complex);
+long double complex catanhl(long double complex);
+long double complex ccosl (long double complex);
+long double complex ccoshl (long double complex);
+long double complex cexpl (long double complex);
+long double complex clogl (long double complex);
+long double complex cpowl (long double complex, long double complex);
+long double complex csinl (long double complex);
+long double complex csinhl (long double complex);
+long double complex ctanl (long double complex);
+long double complex ctanhl (long double complex);
+#endif
#define CAbs(x) cabsl(x)
#define CAcos(x) cacosl(x)
diff --git a/flang-rt/lib/runtime/complex-reduction.c b/flang-rt/lib/runtime/complex-reduction.c
index 967f26c05..99a685bc4 100644
--- a/flang-rt/lib/runtime/complex-reduction.c
+++ b/flang-rt/lib/runtime/complex-reduction.c
@@ -9,6 +9,18 @@
#include "complex-reduction.h"
#include <float.h>
+#ifdef __ANDROID__
+#ifdef CMPLXF
+#undef CMPLXF
+#endif // CMPLXF
+#ifdef CMPLX
+#undef CMPLX
+#endif // CMPLX
+#ifdef CMPLXL
+#undef CMPLXL
+#endif // CMPLXL
+#endif // __ANDROID__
+
struct CppComplexFloat {
float r, i;
};
diff --git a/flang-rt/lib/runtime/time-intrinsic.cpp b/flang-rt/lib/runtime/time-intrinsic.cpp
index 8988817a4..1d5ab0bf4 100644
--- a/flang-rt/lib/runtime/time-intrinsic.cpp
+++ b/flang-rt/lib/runtime/time-intrinsic.cpp
@@ -187,7 +187,7 @@ count_t ConvertTimeSpecToCount(int kind, const struct timespec &tspec) {
return ConvertSecondsNanosecondsToCount(kind, sec, nsec);
}
-#ifndef _AIX
+#if !defined(_AIX) && !(defined(__ANDROID__) && __ANDROID__ < 29)
// More accurate version with nanosecond accuracy
template <typename Unused = void>
count_t GetSystemClockCount(int kind, fallback_implementation) {
EOF
mkdir build-flang-rt
cd build-flang-rt/
cmake ../runtimes -GNinja \
-DLLVM_DIR=$PREFIX/lib/cmake/llvm \
-DLLVM_BINARY_DIR=$PREFIX/bin \
-DCMAKE_Fortran_COMPILER=$(command -v flang) \
-DCMAKE_Fortran_COMPILER_WORKS=yes \
-DLLVM_ENABLE_RUNTIMES=flang-rt
cmake --build . --parallel $(nproc)
# the default folder which is expected to contain libflang_rt.runtime.a by the current flang artifact; maybe it should be changed
mkdir -p $PREFIX/lib/clang/21/lib/aarch64-unknown-linux-android24/
cp flang-rt/lib/libflang_rt.runtime.a $PREFIX/lib/clang/21/lib/aarch64-unknown-linux-android24/
cat > hello.f90 << 'EOF'
program hello
! This is a comment line; it is ignored by the compiler
print *, 'Hello, World!'
end program hello
EOF
flang test.f90 -o hello -static-libflangrt
./hello |
|
I can see that at the same time as I posted that and successfully tested my on-device build of |
e2d4d4e to
7100bfe
Compare
robertkirkman
left a comment
There was a problem hiding this comment.
as mentioned, for a brief period after this is merged mesa will stop working (people who have mesa installed and use pkg upgrade will be unable to get the upgrade and see "packages have been held back: libllvm" which is fine), but I have been testing mesa built locally with this LLVM 21 and there aren't any problems with it that I can find that aren't already also present in mesa built with LLVM 20, so I will upload and merge it shortly after this is merged.
|
Bumped this to the latest patch release, test it out and let us know if you see any problems, including with flang. |
|
These packages are working for me in actual testing after recompiling using LLVM 21.1.2:
This package compiled for me without modifications and without errors, but unfortunately I don't yet know how exactly to use it:
This package fails to compile for me with LLVM 21, but I'm not very familiar with Mingw, so maybe someone else should try to bump and fix it for LLVM 21. If nobody else is available to do so, I could try to bump and fix it myself:
my log of testing clang, flang, rust, crystal and mesa |
I'll have a look after this PR gets merged. |
|
If nobody has any testing complaints, I will update the |
|
Bumped to the latest patch release, will update |
|
Oh no! The aarch64 build timed out after 6 hours! However, (sorry if you also notice this and know about it already, but I am explaining it just in case), I noticed that in this case, it happened because of an intermittent problem that occurs in the Free additional disk space CI step. This step normally takes only 12-15 minutes, but I have noticed that for some reason, it sometimes gets stuck in a slow cycle that takes over an hour, which can use up the available time of long builds and cause them to take longer than 6 hours I suspect that the root cause might have something to do with rate-limiting of Ubuntu mirrors, but unfortunately I'm not sure what a permanent fix would look like. When this happens to me, what I've been doing is just using |
|
Unfortunately, this activity might cause artifacts to be missing after the merge to the master branch, but I'm not entirely sure if this is the kind of job restart which can cause the problem to manifest or not, I am just bringing it up just in case: we can try merging it like this, but I am mentioning it just so that we know to keep an eye out for whether that issue happens or not as a result. (But if this PR will get more force-pushes in order to add the |
|
You can always "Rebase and merge" for the safest option. I will take a look at the CI PR reuse issue... |
…anitizer instead of the shared library - Makes the default behavior of on-device building with the address sanitizer match the default behavior of building with the address sanitizer on Clang for Desktop Linux distros, which is to use the static library - Fixes #26485 - On devices that do not have `libclang_rt.asan-$arch-android.so` or which have a corrupted one, fixes building on-device with `-fsanitize=address` - Samsung Galaxy S III SPH-L710 with LineageOS 14.1 Android 7.1.2 before: ``` ~ $ clang test.c -fsanitize=address ~ $ ./a.out WARNING: linker: /data/data/com.termux/files/home/a.out: unsupported flags DT_FLAGS_1=0x8000001 CANNOT LINK EXECUTABLE "./a.out": library "libclang_rt.asan-arm-android.so" not found Aborted ./a.out ~ $ clang test.c -fsanitize=address -Wl,-rpath=$PREFIX/lib/clang/20/lib/linux ~ $ ./a.out WARNING: linker: /data/data/com.termux/files/home/a.out: unsupported flags DT_FLAGS_1=0x8000001 ~ $ termux-elf-cleaner ./a.out termux-elf-cleaner: Replacing unsupported DF_1_* flags 134217729 with 1 in './a.out' ~ $ ./a.out ~ $ file /system/lib/libclang_rt.asan-arm-android.so /system/lib/libclang_rt.asan-arm-android.so: cannot open `/system/lib/libclang_rt.asan-arm-android.so' (No such file or directory) ~ $ ``` - After: ``` ~ $ clang test.c -fsanitize=address ~ $ ./a.out WARNING: linker: /data/data/com.termux/files/home/a.out: unsupported flags DT_FLAGS_1=0x8000001 ~ $ termux-elf-cleaner a.out termux-elf-cleaner: Replacing unsupported DF_1_* flags 134217729 with 1 in 'a.out' ~ $ ./a.out ~ $ ``` - Vivo iQOO Neo8 V2301A with Android 15 before: ``` thread #1, name = 'a.out', stop reason = signal SIGILL: illegal opcode ``` - After: believed to work
|
This is now ready to go: building one last time then I will merge later today, after which we will need to update rust and so on. |
- See PR #26521 Signed-off-by: Aditya Alok <alok@termux.dev>
- See PR #26521 Signed-off-by: Aditya Alok <alok@termux.dev>
Check if it builds, as I just corrected the patches locally.