[RFC] fix $TERMUX_PREFIX pollution #21835
Conversation
|
Regarding termux-play-store@2bef6d4 - always starting But regardless, this PR is interesting! It's not actually clear to me why we see a lot of build errors such as the ones above:
when building with And in packages that does include cross-compiled Put in another way: If we migrate |
Correct, for the
I'm pretty sure that is correct yes, but it should be noted that
No, if we wait for your PR and go with that, I'm pretty sure it avoids all errors caused by the prefix having other packages installed into it previously (at a very small, surely insignificant speed cost incurred by repeatedly reconstructing the prefix every time a package builds) I use Gentoo, so every time I update my PC, every new package installed is recompiled directly using the same rootfs that I have kept installed since I installed the OS. I guess my method in this PR is just inspired by that, to be able to continuously keep rebuilding and reinstalling all Termux packages in an endless loop, into the same crossbuild prefix, by attempting to universally solve all potential errors that can occur when building the repository that way. |
WIP: changes to
|
I think I recall seeing a very similar error with |
|
I just remembered we have an open PR for updating the NDK 23c patches. I just hadn't had the time to review the earlier PR so far. |
The purpose of changing That means that:
termux-packages/packages/libllvm/build.sh Line 40 in 82ee6f8 |
robertkirkman
force-pushed
the
fix-crossbuild-prefix-pollution-1
branch
from
1f2d119
to
8b35645
Compare
robertkirkman
changed the title
robertkirkman
force-pushed
the
fix-crossbuild-prefix-pollution-1
branch
from
bdc110a
to
53fb59e
Compare
|
@xtkoba one of my changes would permit reverting without build failure occurring. Do you think my method looks like a good replacement for yours, and have you ever happened to see any other similar errors or old workarounds that you think might be relevant to this? I might find more as I continue reading. Validation: git clone https://github.com/termux/termux-packages.git
cd termux-packages/
gh pr checkout 21835
patch -p1 << 'EOF'
--- a/packages/ghostscript/build.sh
+++ b/packages/ghostscript/build.sh
@@ -31,14 +31,6 @@ termux_step_post_get_source() {
termux_step_pre_configure() {
CPPFLAGS+=" -I${TERMUX_STANDALONE_TOOLCHAIN}/sysroot/usr/include/c++/v1"
- # Workaround for build break caused by `sha2.h` from `libmd` package:
- if [ -e "$TERMUX_PREFIX/include/sha2.h" ]; then
- local inc="$TERMUX_PKG_BUILDDIR/_include"
- mkdir -p "${inc}"
- ln -sf "$TERMUX_PKG_SRCDIR/base/sha2.h" "${inc}/"
- CPPFLAGS="-I${inc} ${CPPFLAGS}"
- fi
-
if [[ "${TERMUX_ARCH}" == "aarch64" ]]; then
# https://github.com/llvm/llvm-project/issues/74361
# NDK r27: clang++: error: unsupported option '-mfpu=' for target 'aarch64-linux-android24'
EOF
scripts/run-docker.sh ./build-package.sh -f libmd ghostscriptAnd as a reminder, for clarity, I am pretty sure that since it is an alternative implementation of a solution to the same problem, if a PR using code based on termux-play-store@2bef6d4 eventually comes to this repo, it would also allow reverting that commit. |
robertkirkman
force-pushed
the
fix-crossbuild-prefix-pollution-1
branch
2 times, most recently
from
363d92c
to
3bf2780
Compare
robertkirkman
changed the title
robertkirkman
force-pushed
the
fix-crossbuild-prefix-pollution-1
branch
4 times, most recently
from
a199543
to
2efc9af
Compare
It happens because |
|
@twaik I decided to continue discussion and documenting some more test results regarding the things like
here since this might be a more appropriate thread to talk about it, since I mentioned something about the sysroot already above this in an earlier comment here. The I did not completely invent some of the ideas my changes here are based on by myself, intstead, I happened to be observing the behavior of several toolchains and noticing what they do in various situations, and I have sometimes been taking inspiration from or copying what they do in order to fix some errors that happened when building packages in termux-packages. Gentoo amd64 -> aarch64Gentoo has a package called tacokoneko@CORSAIR ~ $ aarch64-none-linux-gnu-gcc -print-sysroot
/usr/aarch64-none-linux-gnu
tacokoneko@CORSAIR ~ $ ls /usr/aarch64-none-linux-gnu
etc lib lib64 sbin sys-include usr varTermux aarch64
tacokoneko@CORSAIR ~ $ ssh -p 8022 192.168.12.191
[email protected]'s password:
Welcome to Termux!
Docs: https://termux.dev/docs
Donate: https://termux.dev/donate
Community: https://termux.dev/community
Working with packages:
- Search: pkg search <query>
- Install: pkg install <package>
- Upgrade: pkg upgrade
Subscribing to additional repositories:
- Root: pkg install root-repo
- X11: pkg install x11-repo
For fixing any repository issues,
try 'termux-change-repo' command.
Report issues at https://termux.dev/issues
~ $ echo '' | clang -x c - -v 2>&1 | grep -e "--sysroot="
"/data/data/com.termux/files/usr/bin/ld.lld" --sysroot=/data/data/com.termux/files -EL --fix-cortex-a53-843419 -z now -z relro -z max-page-size=16384 --hash-style=gnu -rpath=/data/data/com.termux/files/usr/lib --eh-frame-hdr -m aarch64linux -pie -dynamic-linker /system/bin/linker64 -o a.out /data/data/com.termux/files/usr/lib/crtbegin_dynamic.o -L/data/data/com.termux/files/usr/lib -L/data/data/com.termux/files/usr/aarch64-linux-android/lib -L/system/lib64 /data/data/com.termux/files/usr/tmp/--88abe0.o /data/data/com.termux/files/usr/lib/clang/19/lib/linux/libclang_rt.builtins-aarch64-android.a -l:libunwind.a -ldl -lc /data/data/com.termux/files/usr/lib/clang/19/lib/linux/libclang_rt.builtins-aarch64-android.a -l:libunwind.a -ldl /data/data/com.termux/files/usr/lib/crtend_android.o
~ $
logout
Connection to 192.168.12.191 closed.Termux package builder Docker imageOn the other hand, that argument does not show up in this compiler because it is a prebuilt compiler that comes from a non-Termux source. This means that, technically, to precisely synchronize the exact literal behavior of the cross-compiler and the non-cross-compiler, either tacokoneko@CORSAIR ~ $ code/termux/electric-boogaloo/termux-packages/scripts/run-docker.sh
Running container 'termux-package-builder' from image 'temporary-local-termux-package-builder-image'...
builder@bd15ad372c73:~/termux-packages$ echo '' | /home/builder/.termux-build/_cache/android-r27b-api-24-v1/bin//aarch64-linux-android-clang -x c - -v 2>&1 | grep -e "--sysroot="
builder@bd15ad372c73:~/termux-packages$ |
|
AFAIK NDK's clang puts --sysroot argument automatically when you pass |
|
Good idea, though in my command shown, the result is the same as the equivalent with It seems to have set in it a large number of arguments to use a relative path to set the sysroot at the folder above its folder, i.e. It is not completely clear to me whether or not using |
|
Probably |
|
Sorry if it is too much flooding to continue posting notes like this, but I would like to mention since I just reached the termux-packages/packages/proxmark3/build.sh Lines 13 to 17 in ac069d2 # this is how to shortcut reproduce libmd-related errors like the one you are familiar with,
# without having to run the entire build-all.sh from scratch every time.
# note that it is not always libmd sometimes it is other
# packages, so for similar errors, it's necessary to correctly identify the
# package that comes first in the pollution order
# before it can be reproduced this way. In this specific case it is libmd.
scripts/run-docker.sh ./build-package.sh -I libmd proxmark3
However, what seems like an acceptable solution in this particular case is to adjust the package like this, --- a/packages/proxmark3/build.sh
+++ b/packages/proxmark3/build.sh
@@ -11,8 +11,8 @@ TERMUX_PKG_BUILD_IN_SRC="true"
TERMUX_PKG_BLACKLISTED_ARCHES="i686, x86_64"
termux_step_post_configure() {
- export LDLIBS="-L${TERMUX_PREFIX}/lib"
- export INCLUDES="-I${TERMUX_PREFIX}/include"
+ export LDLIBS="$LDFLAGS"
+ export INCLUDES="$CPPFLAGS"
TERMUX_PKG_EXTRA_MAKE_ARGS="client CC=$CC CXX=$CXX LD=$CXX cpu_arch=$TERMUX_ARCH SKIPREVENGTEST=1 SKIPQT=1 SKIPPTHREAD=1 SKIPGD=1 PLATFORM=PM3GENERIC"
}That allows the command I'll probably commit that to this PR soon as my change for |
It is easy. Make and ninja print the command which fail. You simply add termux's toolchain path to PATH and navigate to build folder like and invoke the failing clang command with After this you only should the package providing the file with |
robertkirkman
force-pushed
the
fix-crossbuild-prefix-pollution-1
branch
2 times, most recently
from
e72423c
to
42b3238
Compare
robertkirkman
force-pushed
the
fix-crossbuild-prefix-pollution-1
branch
2 times, most recently
from
2547033
to
88ba2e0
Compare
|
That was really weird, I pushed a change to the This was the run that failed and then when I deleted the commit, re-committed and force pushed without making any code changes it succeeded. https://github.com/termux/termux-packages/actions/runs/11582453980 |
…chain/27b}): fix crossbuild prefix pollution
…ny binaries when TERMUX_PACKAGE_LIBRARY is glibc, including bin/sh
to detect current $TERMUX_PREFIX state and prevent "ld.lld: error: unable to find library -liberty" when the binutils-libs package was already installed in the same $TERMUX_PREFIX before building liblightning.
… fix prefix pollution for libprotozero when testing the build of libprotozero, I noticed it hits the edge case for when there is a binary that can't be symlinked because there aren't any x86 copies of it installed, so this fixes that and also fixes a bug in the build system of libprotozero in which protobuf is not meant to be detected. patch copied and pasted from https://git.buildroot.net/buildroot/commit/?id=e54b82306d005eeb4ed013a4cbd39e59e5ea8f19
…from scripts/build/toolchain Fixes "src/cmdflashmem.c:81:5: error: call to undeclared function 'mbedtls_sha1'" when the command "scripts/run-docker.sh ./build-package.sh -I libmd proxmark3" is run.
…nstead of deleting binaries Fixes handle_incompatible_binary() for ragel/colm
…bseccomp is installed Code copied and pasted from hauke/packages@95aef02
…d previously Fixes "ld.lld: error: undefined symbol: ltm_desc"
robertkirkman
force-pushed
the
fix-crossbuild-prefix-pollution-1
branch
from
681eabe
to
242f9e6
Compare
…d in $TERMUX_PREFIX
When the mariadb is built like this,
scripts/run-docker.sh ./build-package.sh -I fmt mariadb
it prints this and stops:
```
CMake Error: try_run() invoked in cross-compiling mode, please set the following cache variables appropriately:
HAVE_SYSTEM_LIBFMT_EXITCODE (advanced)
For details see /home/builder/.termux-build/mariadb/build/TryRunResults.cmake
```
The contents of that file show this:
```
This file was generated by CMake because it detected try_run() commands
in crosscompiling mode. It will be overwritten by the next CMake run.
Copy it to a safe location, set the variables to appropriate values
and use it then to preset the CMake cache (using -C).
HAVE_SYSTEM_LIBFMT_EXITCODE
indicates whether the executable would have been able to run on its
target platform. If so, set HAVE_SYSTEM_LIBFMT_EXITCODE to
the exit code (in many cases 0 for success), otherwise enter "FAILED_TO_RUN".
HAVE_SYSTEM_LIBFMT_EXITCODE__TRYRUN_OUTPUT_STDOUT
contains the text the executable would have printed on stdout.
If the executable would not have been able to run, set HAVE_SYSTEM_LIBFMT_EXITCODE__TRYRUN_OUTPUT_STDOUT empty.
Otherwise check if the output is evaluated by the calling CMake code. If so,
check what the source file would have printed when called with the given arguments.
HAVE_SYSTEM_LIBFMT_EXITCODE__TRYRUN_OUTPUT_STDERR
contains the text the executable would have printed on stderr.
If the executable would not have been able to run, set HAVE_SYSTEM_LIBFMT_EXITCODE__TRYRUN_OUTPUT_STDERR empty.
Otherwise check if the output is evaluated by the calling CMake code. If so,
check what the source file would have printed when called with the given arguments.
The HAVE_SYSTEM_LIBFMT_COMPILED variable holds the build result for this try_run().
Executable : /home/builder/.termux-build/mariadb/build/CMakeFiles/cmTC_076b0-HAVE_SYSTEM_LIBFMT_EXITCODE
Run arguments :
Called from: [4] /home/builder/.termux-build/_cache/cmake-3.30.4/share/cmake-3.30/Modules/Internal/CheckSourceRuns.cmake
[3] /home/builder/.termux-build/_cache/cmake-3.30.4/share/cmake-3.30/Modules/CheckCXXSourceRuns.cmake
[2] /home/builder/.termux-build/mariadb/src/cmake/libfmt.cmake
[1] /home/builder/.termux-build/mariadb/src/CMakeLists.txt
set( HAVE_SYSTEM_LIBFMT_EXITCODE
"PLEASE_FILL_OUT-FAILED_TO_RUN"
CACHE STRING "Result from try_run" FORCE)
```
These directions are telling me to run the binary
"cmTC_076b0-HAVE_SYSTEM_LIBFMT_EXITCODE" on the target device. I ran
that binary on a clean installed, then fully updated aarch64 Termux app
and the return code was 0. That seems to me to indicate that this should
be set to 0 in $TERMUX_PKG_EXTRA_CONFIGURE_ARGS.
When I apply this change, the mariadb build completes successfully while
fmt was installed in the prefix.
robertkirkman
force-pushed
the
fix-crossbuild-prefix-pollution-1
branch
from
242f9e6
to
0aca8a3
Compare
|
Probably it is time for final review for this PR. We have some issue with updating/uploading a lot of packages at once. |
Ok, in that case I need to think about how to organize it into several separate PRs I think, that are smaller and more pinpointed to the exact changes they are relevant to. For example, the whole large blue Note at the beginning could be separated out into its own PR, and the code associated with it is ready. On the other hand, several of the other changes besides that one are not ready yet, so rather than continuing to lump all of my changes of the type that you usually describe as " One of the reasons I decide to mark my own The reason I believe that is because, it is my understanding that gradual replacement of dependencies in packages over time, as they receive updates, can subtly shift the build order calculated by I definitely want to try to prevent as many potential errors in my code as possible by fully testing all cross-compiling codepaths in a way that works for any potential build order. Also if you want to, it is completely OK to copy anything from this PR and put it into your own PRs if there is anything you want to use that you believe is ready and should be in the main repo faster. |
|
On the one hand you are right, it is good to commit all changes at once. |
|
Regarding the viability of
export CPPFLAGS+=" -isysroot$(dirname $TERMUX_PREFIX/)"
export CPPFLAGS+=" -isysroot$TERMUX_PREFIX"
export CPPFLAGS+=" -isysroot$TERMUX_PREFIX/include"
export CPPFLAGS+=" -isystem$TERMUX_PREFIX/include"Based on this result, it seems, at least to me, like |
|
If anyone worries that this one is taking too long, do not worry I will finish it, I just stopped uploading it because of the CI concern. When certain parts are ready I will make them each as separate PRs. There is a medium sized block of code in the There's another instance of a preexisting localized variant of the same symlink technique in the If the package's configure script fails with a message like this, it might be attempting to detect a binary that should be in
It should enable removing all lines that follow the same pattern that this line follows. termux-packages/packages/git/build.sh Lines 80 to 81 in 280b51c In the way I do it, the handling of the "build machine" binary symlink happens outside of and isolated from the package changed-file detection section of the code, meaning that a single instance of this symlink can be shared between several packages to serve the exact same purpose, e.g. It should be noted that Short summary explaining some edge cases:
as I tally those up, I guess what I decide the final fallback behavior should be will change to whichever one has a longer list, since making the fallback behavior match the majority of edge cases will minimize the amount of packages that have to be explicitly named in a string. |
|
I do not like to store too many changes only locally without backing them up in the cloud and other backups periodically, because I am afraid of storage corruption, so I am posting a snapshot of my current local changes here, and I will probably copy and paste the changes there that are not already separated into different PRs, into other PRs, once they are ready. I noticed from previous discussion that the granularity and documentation of any potential changes to the file |
Fixes #20336 and progress on #21130
When using a
$TERMUX_PREFIX, i.e. atermux-package-builderDocker container, that compiled and installed other packages previously, or a Termux environment that has installed other packages previouslyNote
The priority is the cross-compilation mode first because many packages have other, unrelated errors when cross-compilation is disabled, so the cross-compilation mode should be considered first before analyzing the behavior of building within Termux environments, even though some of these errors are reproducible in both modes.
Tip
Cross-compilation-specific error category
Below this are errors this PR has fixes for that are probably only reproducible with cross-compilation, while building the same packages with cross-compilation disabled probably either works or produces other, very different errors
Note
When I put the code to fix this first error together with the rest of the code in this PR, I sort of considered it as "close enough" to the same type of thing because it's approximately 2 lines away from the code for the other error below this, and it both shows up in similar use cases and has similar effects on
stderrto the other errors - but to be 100% clear in my explanation, I need to explain that technically, this one error is not actually triggered by having other packages installed before buildingmesa, it is directly triggered by:scripts/run-docker.sh build-package.sh mesawithout the-Iargumentdue to a build system edge case that does not actually involve the factor that
-Iinstalls fewer packages into the$TERMUX_PREFIXthan building with no arguments does, but instead purely logic within thescriptsfolder andbuild-package.sh.How, exactly, to reproduce
ERROR: Failed running '/data/data/com.termux/files/usr/bin/llvm-config', binary or interpreter not executable:It happens because
$TERMUX_INSTALL_DEPSis set tofalseand never back totrueby anything in this codepath except the-Iargument, so the end result is that the necessary version ofllvm-confignever gets installed intermux_step_override_config_scripts().termux-packages/scripts/build/termux_step_setup_variables.sh
Line 7 in 70b3295
termux-packages/build-package.sh
Lines 490 to 494 in 70b3295
termux-packages/scripts/build/termux_step_override_config_scripts.sh
Lines 10 to 12 in 70b3295
termux-packages/scripts/build/termux_step_override_config_scripts.sh
Line 32 in 9ebb185
I hope that all helps with understanding the
llvm-configerror. I could be wrong about grouping it into the same PR as the other changes, but I feel like it probably can still be considered one of the forms of "$TERMUX_PREFIXpollution" because it's an invalid state of the cross-compilation docker container that prevents cross-compilingmesa.Fixes
ERROR: Failed running '/data/data/com.termux/files/usr/bin/llvm-config', binary or interpreter not executable.mesa+ possiblyrustFixes
Interpreter: Cannot run the interpreter "/data/data/com.termux/files/usr/bin/python3"and similar errors involving around 15 to 20 other binaries that are notpython3, such assedandxsltprocin:mesalibprotozerolibtheoraFixes many errors similar to
nasmlib/md5c.c:46:10: error: no member named 'buf' in 'struct MD5Context'in:nasmbitlbeeemacsgdblibjxllibmediainfomaxcsonodejspipewirerustsqlciphertome2wegglizipproxmark3handbrakeFixes
CMake Error: try_run() invoked in cross-compiling modemariadbTip
Universal error category
Below this are errors this PR has fixes for that are probably reproducible in both cross-compiling and non-cross-compiling modes.
Fixes
sl.c:51:10: fatal error: 'curses.h' file not foundsland any other package that requirescurses.h.Fixes
ld.lld: error: unable to find library -libertyliblightningFixes
The dependency target "writer_tests" of target "clang-tidy" does not exist.libprotozeroFixes build with
libseccompinstalled in the$TERMUX_PREFIXbefore buildtorFixes
ld.lld: error: undefined symbol: ltm_desc(NOTE: my change fordropbearcauses CI to fail, but does not fail in my local build, I don't know why yet)dropbearI have not finished testing all the codepaths I want to test these changes on,
but I would like to know, do you know any better solutions to these errors or better ways to write these changes?
The commit guidelines say you have an 80 column limit, but the same file I edited already has multiple 120+ column lines, leaving me confused. Should I reformat the entire file to fit in 80 columns?
Also, the commit guidelines do not have very many directions regarding changes to the
scriptsfolder, leaving me unsure whether I'm following the correct coding style in general for this folder.Possibly preexisting alternative solution
I strongly suspect that termux-play-store/termux-packages works around/bypasses many of these errors using a very different codepath. It is possible that maybe fornwall prefers that method over this one, so if that repo is going to combine into this repo someday, maybe it's better to use that solution instead.