termux
[Bug]: Build error when building mesa
Problem description
When I was trying to build mesa I got this error during the configuration process: ../src/src/compiler/spirv/meson.build:83:23: ERROR: Tried to mix a host machine library ("vtn") with a build machine target "vtn_bindgen2" This is not possible in a cross build. I don't understand what this means and how will I be able to fix it? (Im using the Mako version from the Github main branch build)
What steps will reproduce the bug?
Just run the build script
What is the expected behavior?
It should continue and build mesa
System information
Termux Variables: TERMUX_APP_PACKAGE_MANAGER=apt
TERMUX_APP__APK_FILE=/data/app/~~4rFupKtyCS26JXpxBeyHfA==/com.termux-7MeSW6NMqszwrnvf68r5eA==/base.apk
TERMUX_APP__APK_RELEASE=GITHUB
TERMUX_APP__APP_VERSION_CODE=1022
TERMUX_APP__APP_VERSION_NAME=0.119.0-beta.3
TERMUX_APP__DATA_DIR=/data/user/0/com.termux
TERMUX_APP__IS_DEBUGGABLE_BUILD=true
TERMUX_APP__IS_INSTALLED_ON_EXTERNAL_STORAGE=false
TERMUX_APP__LEGACY_DATA_DIR=/data/data/com.termux
TERMUX_APP__PACKAGE_NAME=com.termux
TERMUX_APP__PID=13058
TERMUX_APP__SE_FILE_CONTEXT=u:object_r:app_data_file:s0:c36,c257,c512,c768
TERMUX_APP__SE_INFO=default:targetSdkVersion=28:complete
TERMUX_APP__TARGET_SDK=28
TERMUX_VERSION=0.119.0-beta.3
TERMUX__APPS_DIR=/data/user/0/com.termux/termux/apps
TERMUX__HOME=/data/data/com.termux/files/home
TERMUX__PREFIX=/data/data/com.termux/files/usr
TERMUX__ROOTFS_DIR=/data/data/com.termux/files
TERMUX__SE_PROCESS_CONTEXT=u:r:untrusted_app_27:s0:c36,c257,c512,c768
TERMUX__UID=10292
TERMUX__USER_ID=0
Packages CPU architecture:
aarch64
Subscribed repositories:
# sources.list
deb https://termux.danyael.xyz/termux/termux-main stable main
# x11-repo (sources.list.d/x11.list)
deb https://termux.danyael.xyz/termux/termux-x11 x11 main
Updatable packages:
All packages up to date
termux-tools version:
1.45.0
Android version:
15
Kernel build information:
Linux localhost 5.15.167-android13-8-31019773 #1 SMP PREEMPT Mon Jun 30 05:52:20 UTC 2025 aarch64 Android
Device manufacturer:
samsung
Device model:
SM-A156U1
Supported ABIs:
SUPPORTED_ABIS: arm64-v8a,armeabi-v7a,armeabi
SUPPORTED_32_BIT_ABIS: armeabi-v7a,armeabi
SUPPORTED_64_BIT_ABIS: arm64-v8a
LD Variables:
LD_LIBRARY_PATH=
LD_PRELOAD=/data/data/com.termux/files/usr/lib/libtermux-exec-ld-preload.so
Installed termux plugins:
com.termux.widget versionCode:1000
com.termux.api versionCode:1001
com.termux.x11 versionCode:15
(Im using the Mako version from the Github master build)
I'm not entirely sure what you are referring to there.
(Im using the Mako version from the Github master build)
I'm not entirely sure what you are referring to there.
I meant the "main" branch sorry. From here: https://github.com/sqlalchemy/mako
Does
mesause Mako templates or what's the relation here?
Mako is one of Mesa's build dependencies. It will fail if it can't find it. The pip version goes unnoticed.
Hmm mesa builds fine for me locally in the build container on my PC.
I can't try an on-device build right now unfortunately.
Hmm
mesabuilds fine for me locally in the build container on my PC. I can't try an on-device build right now unfortunately.
I was doing an on device build and it failed. I don't have a PC to do a non-on-device build.
Hmm
mesabuilds fine for me locally in the build container on my PC. I can't try an on-device build right now unfortunately.I was doing an on device build and it failed. I don't have a PC to do a non-on-device build.
@alexdvn
This issue is most likely a duplicate of:
- https://github.com/termux/termux-packages/issues/21658
The PR that will fix that issue (on-device build of package mesa) is this:
- #23652
If you would like to test my PR, please try following the steps I have posted in this comment:
- https://github.com/termux/termux-packages/pull/23652#issuecomment-3215698446
If, after following the steps to test my PR that I have linked in the comment I posted, you are still experiencing the error
ERROR: Tried to mix a host machine library ("vtn") with a build machine target "vtn_bindgen2"
please let me know, because in that case, this issue would be a separate issue and not a duplicate of
- https://github.com/termux/termux-packages/issues/21658
Repeating steps here to help you find them in case the exact message is hard to find due to the very large amount of messages in the other thread:
git clone -b exclude-pycache-during-extract-into-massagedir https://github.com/robertkirkman/termux-packages.git
cd termux-packages/
scripts/setup-termux.sh
./build-package.sh -I -f mesa
cd output/
apt reinstall ./*.deb
I can't try an on-device build right now unfortunately.
no problem about this @TomJo2000, but I wondered a little bit, do you not test on-device builds since they use up a lot of device resources like battery, storage, network, multitasking performance, Termux installation cleanliness and screen burn-in time, that you don't have enough of available,
or is it more that you choose to maintain only cross-compilations as a strategic choice about which parts of the codebase you maintain, so that your efforts are focused on a specific problem domain, and your time isn't stretched too thinly over too many different areas of the codebase?
If it builds on the CI that's mission accomplished in my books. I don't have the time and energy to run on-device builds for everything as well.
That makes sense and is completely understandable.
From a certain perspective, it might be said that each time the on-device build of something is fixed, that is technically adding small new fixes or "features" to the package packages/libllvm/clang.subpackage.sh, which is itself a package that technically was produced by cross-compilation, because the purpose of the clang package is open-ended on-device compilation with no clearly defined boundary at which it "should not support" compiling something,
but from that perspective, the additional impact of each newly possible on-device build is only adding a very tiny amount of functionality to the clang package in the big picture of all other packages that originated from cross-compilation, so fixing cross-compilations of things has a vastly greater overall impact since a cross-compiled thing can usually then become its own entire official package, rather than a tiny additional feature in an already-existing package.