fix(toolchain/{23c,27c}): add -isystem${TERMUX_PREFIX}/include/c++/v1 to $CPPFLAGS before -isystem${TERMUX_PREFIX}/include

[robertkirkman]

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

• ghostscript: cleans up $CPPFLAGS and adds tested $TERMUX_ON_DEVICE_BUILD=true support

• octave, octave-x: revbump after db889e1 to fix propagated $CPPFLAGS, also adjusts the propagated linker flags so that the pkg function of Octave (https://octave.sourceforge.io/octave/function/pkg.html) can successfully compile C++ code inside of Octave without this 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'

[robertkirkman]

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)

[licy183]

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).

[robertkirkman]

@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

termux-packages/scripts/build/termux_step_get_dependencies.sh

Lines 28 to 29 in fe7adf6

	# llvm doesn't build if ndk-sysroot is installed:
	if [ "$PKG" = "ndk-sysroot" ]; then continue; fi

• 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

termux-packages/packages/ndk-sysroot/build.sh

Lines 75 to 76 in fe7adf6

	cp -Rf toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/* \
	$TERMUX_PKG_MASSAGEDIR/$TERMUX_PREFIX/include

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?

[robertkirkman]

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

[robertkirkman]

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.

[robertkirkman]

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.

[licy183]

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.

[robertkirkman]

Ok, I will reorganize the commit structure soon

[robertkirkman]

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

[licy183]

LGTM

[robertkirkman]

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.