The reason why this has to stay as -isystem for the cross-compiler, and could not be replaced with -isysroot to match the argument that is automatically applied by the on-device compiler, is because the cross-compiler has a /home/builder/.termux-build/_cache/android-r27c-api-24-v1/sysroot/usr/include folder containing some necessary C headers separately, that the on-device compiler does not have, and adding -isysroot interferes with that when using the cross-compiler:

#21835 (comment)

Since #23513 breaks the on-device build, after python is rebuilt after it, the building process triggered by pip may also be broken. See #20464 (comment).

@licy183 Thank you for explaining, I do see that after you showed me. Python does store the $CPPFLAGS among other flags in $TERMUX_PREFIX/lib/python3.12/_sysconfigdata__linux_.py.

Do you know of a pip package that builds C++, rather than only C, that I could test, which I have not found yet, and do you think this other way I have pushed will solve the problem?

This other way passes these test cases while using the same $CPPFLAGS in both $TERMUX_ON_DEVICE_BUILD=true mode and $TERMUX_ON_DEVICE_BUILD=false mode:

• ghostscript (a C++ package) both cross-compiled and on-device builds (on-device build support added in this PR because it is idiomatic since it was previously touched by scripts(toolchain): several changes related to $TERMUX_PREFIX/include #23513)
• htop (a C-only package) both cross-compiled and on-device builds
• libcln (a C++ package) both cross-compiled and on-device builds
• pypy and pypy3 (uncommon edge cases) (from bionic-host: rename to aosp-libs, bump to 9.0.0-r76, add aosp-utils subpackage, revbump revdeps #22906)

and this change should do nothing for cross-compiling of all normal C or C++ packages, because the cross-compiler will continue to include the correct C++ headers, in the correct order, in its own way that has been successful so far, from /home/builder/.termux-build/_cache/android-r27c-api-24-v1/sysroot/usr/include/c++/v1, and since there is nothing in $TERMUX_PREFIX/include/c++/v1, this argument should always have no effect in cross-compilation mode.

I think that these two already-existing parts of the repository code save me from the frightening idea of ndk-sysroot ever getting into the $TERMUX_PREFIX in $TERMUX_ON_DEVICE_BUILD=false mode and adding headers from a too-new version of LLVM into the include path:

• ndk-sysroot is already prevented from ever being installed into $TERMUX_PREFIX during build-package.sh as a dependency of any package

• ndk-sysroot's build.sh already carefully avoids installing anything into $TERMUX_PREFIX/include during scripts/run-docker.sh ./build-package.sh -I -f ndk-sysroot, instead intentionally installing into $TERMUX_PKG_MASSAGEDIR

and I am pretty sure that on-device, the headers in ${TERMUX_PREFIX}/include/c++/v1 are designed to be safe for being in the $CPPFLAGS of C-only programs, because they contain things like "#if defined(__cplusplus)" and "#if __has_include_next(<stdint.h>) # include_next <stdint.h>", but I hope that there is not a situation where a C-only program would be derailed and fail to build on-device if exposed to the addition of -isystem${TERMUX_PREFIX}/include/c++/v1. Do you know of any?

licy183 you are completely right, because, very unfortunately, after db889e1, it has already happened to octave, exactly as you predicted, and

pkg install octave
octave
pkg install https://sourceforge.net/projects/octave-ocl-extra/files/ocl-1.2.2-AMD-update.tar.gz/download

• started manifesting [Bug]: building C++ packages on-device broken #23578

So it must be revision-bumped in this PR, to make that error go away. I am very sorry for causing the error.

• This is a separate issue from [termux-apt] octave from TUR and other problematic unofficial packages are difficult to remove #23605 , which is just a different bug in the same package that has existed for much longer

  • (so, to get to the point where the newer error occurs, you must have an Android 9 or older device capable of bypassing that issue)

• There is also a third error currently affecting the octave package, which I am pretty sure I did not cause, that you can see after bypassing the first two errors. The on-device linker arguments somewhere in the octave package have begun at some point to be polluted by linker arguments from the cross-compiler, not just the preprocessor arguments. I don't know how to fix the linker arguments error, which I am pretty sure was there before I did anything:

clang++: error: no such file or directory: '/home/builder/.termux-build/_cache/android-r27c-api-24-v1/lib/clang/18/lib/linux/libclang_rt.builtins-aarch64-android.a'
make: *** [Makefile:48: ocl_bin.oct] Error 1

~ $ for f in $(dpkg -L octave); do grep -d skip 'build/_cache' $f; done
grep: /data: Permission denied
grep: /data/data: Permission denied
grep: /data/data/com.termux/files/usr/bin/mkoctfile-9.4.0: binary file matches
grep: /data/data/com.termux/files/usr/lib/octave/9.4.0/liboctinterp.so: binary file matches
Libs.private: -lcurl -lcholmod -lumfpack -lamd -lcamd -lcolamd -lccolamd -lcxsparse -lsuitesparseconfig -lspqr -larpack -lqrupdate -lopenblas -lfftw3_threads -lfftw3 -lfftw3f_threads -lfftw3f  -lopenblas -L/data/data/com.termux/files/usr/lib -lreadline  -lpcre2-8  -lpthread  /home/builder/.termux-build/_cache/android-r27c-api-24-v1-flang-v0/sysroot/usr/lib/aarch64-linux-android/libFortranRuntime.a /home/builder/.termux-build/_cache/android-r27c-api-24-v1-flang-v0/sysroot/usr/lib/aarch64-linux-android/libFortranDecimal.a -lpthread -lm -landroid-complex-math      -lcrypto    -L/data/data/com.termux/files/usr/lib -liconv   
grep: /data/data/com.termux/files/usr/bin/mkoctfile: binary file matches

I did something to Octave that made the third error, clang++: error: no such file or directory: '/home/builder/.termux-build/_cache/android-r27c-api-24-v1/lib/clang/18/lib/linux/libclang_rt.builtins-aarch64-android.a', go away on my Android 8 device.

After that, it turned into a fourth error, "error: octave's dynamic library loader reported an error while dynamically loading the OpenCL library",

which is a dlopen("libOpenCL.so") kind of error, so I think it is not directly related to compiling and running C++ inside of Octave.

The text of the fourth error itself, comes from inside of a C++ function, so I think it serves as proof that compiling C++ code inside of Octave started working. What is remaining is that OpenCL itself is not working, and possibly just not working on my particular device.

However, the patch I made is extremely weird looking and hard to explain. It is patching a feature --enable-relocate-all that is already in Octave, but which was designed for cross-compilers that have only 1 prefix. The problem here is that the termux-packages toolchain here is a cross-compiler with at least three different prefixes all at the same time, $TERMUX_PREFIX, $flang_toolchain_dir/sysroot/usr, and $TERMUX_STANDALONE_TOOLCHAIN, so to completely patch $TERMUX_TOPDIR out of the target package, it is necessary to modify the behavior of the --enable-relocate-all setting to handle the $flang_toolchain_dir/sysroot/usr and $TERMUX_STANDALONE_TOOLCHAIN that are not expected by the upstream code. I hope that it makes sense to someone.

Also I did not want to touch even more files in this PR, so I have not messed with it, but it looks to me like termux_setup_flang() will sometimes use cd and then not go back to the original directory that was active when termux_setup_flang() was called. I am not sure if that is intentional or not so I just used cd "$TERMUX_PKG_SRCDIR" to work around that safely.

Also, in the future version of Octave, they tested it on Windows and had some kind of a similar problem, so they modified the file adding a Windows block into the same spot, so the patch will fail and need to be rebased at that time. I hope I have explained it well enough that it will not be frustrating when that happens.

Please separate these changes into three commits. It is better to write a brief comment of each change in build.sh, and put more explanation in the commit msg. Other things LGTM.

Ok, I will reorganize the commit structure soon

I separated the commits, reduced the comments, and moved the information into the commit messages, I hope this makes it more organized and readable

Ok I will merge this in 24 hours, if nothing else is found wrong with it. I have been testing the addition of -isystem${TERMUX_PREFIX}/include/c++/v1 on many packages in both cross-compilation and non-cross-compilation modes and I am pretty sure now that it will not break any builds.