rust package is broken

[luisdavim]

Problem description

Rust got uninstalled after upgrading and can't install it back

$ apt install rust
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 rust : Depends: libllvm (< 16) but 16.0.0 is to be installed
E: Unable to correct problems, you have held broken packages.

What steps will reproduce the bug?

Just run:

$ apt update; apt upgrade; apt install rust

What is the expected behavior?

Rust to be installable

System information

termux-info:

Termux Variables:
TERMUX_API_VERSION=0.50.1
TERMUX_APK_RELEASE=F_DROID
TERMUX_APP_PACKAGE_MANAGER=apt
TERMUX_APP_PID=16705
TERMUX_IS_DEBUGGABLE_BUILD=0
TERMUX_MAIN_PACKAGE_FORMAT=debian
TERMUX_VERSION=0.118.0
Packages CPU architecture:
aarch64
Subscribed repositories:
# sources.list
deb https://packages-cf.termux.dev/apt/termux-main/ stable main
Updatable packages:
All packages up to date
termux-tools version:
1.37.0
Android version:
13
Kernel build information:
Linux localhost 5.15.41-android13-8-25800099-abS918BXXS1AWBM #1 SMP PREEMPT Thu Mar 2 11:53:51 UTC 2023 aarch64 Android
Device manufacturer:
samsung
Device model:
SM-S918B
LD Variables:
LD_LIBRARY_PATH=
LD_PRELOAD=/data/data/com.termux/files/usr/lib/libtermux-exec.so

[TheAwesome98-Real]

can repro

[silveroxides]

commit 0727af2 broke it I suppose.

[finagolfin]

Known issue when updating LLVM, someone will need to update or rebuild the rust package.

[gabldotink]

Also experiencing this issue. Note that rust depends on libllvm (< 16), but it looks like it's supposed to be < 17. rust's build script takes the latest major version of libllvm listed in its build script and adds 1, then uses that as an above-maximum version:

_LLVM_MAJOR_VERSION=$(. $TERMUX_SCRIPTDIR/packages/libllvm/build.sh; echo $LLVM_MAJOR_VERSION)
_LLVM_MAJOR_VERSION_NEXT=$((_LLVM_MAJOR_VERSION + 1))
TERMUX_PKG_DEPENDS="libc++, clang, openssl, lld, zlib, libllvm (<< $_LLVM_MAJOR_VERSION_NEXT)"

but it must somehow be keeping _LLVM_MAJOR_VERSION_NEXT as 16, which is the latest version, but also unintentionally too high of one.

edit: this is incorrect

[finagolfin]

@gabldotink, no, that's intentional. The idea is that if LLVM is updated, rather than breaking the current rust package, it won't allow you to install the rust linked against the old LLVM 15.

Someone will need to rebuild rust against LLVM 16, as has always happened on past LLVM updates.

[adarshhegde]

Facing the same issue when trying to install rust

[silveroxides]

@gabldotink, no, that's intentional. The idea is that if LLVM is updated, rather than breaking the current rust package, it won't allow you to install the rust linked against the old LLVM 15.

Someone will need to rebuild rust against LLVM 16, as has always happened on past LLVM updates.

So you made the commit knowing this would be the case beforehand? Yet you did not come to the logical conclusion that this would be something that should be coordinated to avoid situations like these?
Then least you could have done was to put some effort in to commit description and add a mention of that when committing.

[xtkoba]

This is partly due to the behavior of pkg command, which tries to remove rust by default:

$ pkg upgrade
No mirror or mirror group selected. You might want to select one by running 'termux-change-repo'
Checking availability of current mirror:
[*] https://packages-cf.termux.dev/apt/termux-main/: ok
Hit:1 https://packages-cf.termux.dev/apt/termux-main stable InRelease
Hit:2 https://packages-cf.termux.dev/apt/termux-x11 x11 InRelease
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
7 packages can be upgraded. Run 'apt list --upgradable' to see them.
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages will be REMOVED:
  rust
The following packages will be upgraded:
  clang libcompiler-rt libllvm lld llvm mesa mesa-dev
7 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
Need to get 87.3 MB of archives.
After this operation, 321 MB disk space will be freed.
Do you want to continue? [Y/n] n
Abort.

pkg upgrade is redirected to apt full-upgrade which results in this behavior, while using apt-get upgrade does not cause this because upgrading of libllvm suite is kept back:

$ apt-get upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
  clang libcompiler-rt libllvm lld llvm
The following packages will be upgraded:
  mesa mesa-dev
2 upgraded, 0 newly installed, 0 to remove and 5 not upgraded.
Need to get 11.3 MB of archives.
After this operation, 1798 kB of additional disk space will be used.
Do you want to continue? [Y/n] n
Abort.

I have no idea whether this behavior of pkg upgrade can be (or should be) improved.

[finagolfin]

So you made the commit knowing this would be the case beforehand?

Yep, this happens every six months with every major LLVM update I put out.

Yet you did not come to the logical conclusion that this would be something that should be coordinated to avoid situations like these?

Read the comment I linked, where I notified the two devs who had most recently updated the rust package ahead of time.

Then least you could have done was to put some effort in to commit description and add a mention of that when committing.

That makes no difference. What makes a difference is letting the recent maintainers know, as this is a long-standing known issue when updating LLVM or any other commonly used library, ie some of the dependencies break because they don't work with the latest library version.

With the Rust package, usually one of the volunteer maintainers steps up and updates it. If nobody has done so this time, perhaps one of you can do so.

[TheAwesome98-Real]

perhaps one of you can do so.

i'd like to, but i have no idea how as i have never built rust before (i have only used rustup and it does not work on android)

[predrag42on]

I see that the older version of llvm is also removed? https://termux.mentality.rip/termux-main/pool/main/libl/libllvm/
Is there no way to revert now? I really need my rust! 😢

[jwaxy]

I am experiencing the same issue right now. Can I downgrade llvm?

[BHH95]

same issue here. android termux

[jowparks]

Is there no workaround? Can we manually install older version of libllvm to unblock?

[finagolfin]

Try this:

apt remove libllvm
dpkg -i ~/../../cache/apt/archives/{clang,libcompiler-rt,libllvm,lld,llvm}_15.0.7-3*deb
dpkg -i ~/../../cache/apt/archives/rust_1.68.1*deb

As long as you haven't cleaned your downloaded Termux package cache lately, which most people don't, that should work. You may need to check the libllvm version you last installed though, as if it wasn't 15.0.7-3, you will have to substitute the version you have in this command.

If that works, don't update your packages until rust is rebuilt against LLVM 16 and you should be good for a bit.

[jowparks]

Hmm I am working with a fresh install of termux, so I don't have a cache.

I am new to the ecosystem, I am pretty surprised there is a breaking update every six months and there is no version archiving. I don't think it should be on you to do the upgrade for llvm @buttaface but it seems crazy there is no failsafe for the end user. This seems like a termux level decision, still I am just shocked

[finagolfin]

I would characterize this as more of a bleeding-edge repo, we're currently listed as the fifth most up-to-date package repo at repology. One of the hazards of updating quickly is breaking dependencies that don't update as quick, which is why many package repos go slower or maintain a more stable branch too.

We could mitigate this somewhat by keeping a couple older versions on the server, and having commands to roll back broken packages to those older versions, but have not done so.

[predrag42on]

Thank you! this saved my ass. I'll just use apt from now on instead of pkg to avoid breaking my system (@xtkoba thanks for the tip on how pkg works).

[huidaoweilai2024]

I see that the older version of llvm is also removed? https://termux.mentality.rip/termux-main/pool/main/libl/libllvm/ Is there no way to revert now? I really need my rust! 😢

https://mirror.nevacloud.com/applications/termux/termux-main/
https://linux.domainesia.com/applications/termux/termux-main/

[pschmitt]

If you are impatient you can grab the build artifacts produced by #15876

https://github.com/termux/termux-packages/actions/runs/4573314657

[finagolfin]

Can someone try out the new rust build and let us know if it works well?

Download the right zip artifact for your architecture here and unzip and untar it.

Then, update to LLVM 16 and run dpkg -i debs/rust_1.68.2*deb before checking how it works.

[s-cerevisiae]

I tried to compile rust-analyzer with it.
First try always ends up with a linker error:

= note: LLVM ERROR: SmallVector unable to grow. Requested capacity (4294967296) is larger than maximum value for size type (4294967295)
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
clang-16: error: unable to execute command: Aborted
clang-16: error: linker command failed due to signal (use -v to see invocation)

But if I run the build command again it passes and the resulting binary works normally.

Idk if it's because of my clang installation (was also broken, "fixed" with apt --fix-broken install)

[finagolfin]

There are sporadic linker crashes with lld 16, #15867, so that's unrelated.

What was the clang installation issue? Paste an error if you still have it.

[2096779623]

grex builds successfully, but clang package is also broken.

[luisdavim]

Updated and it seems to be working fine. Thanks

[finagolfin]

@s-cerevisiae, question for you: what CPU were you running on when you hit that linker error? I'm reporting the linker issue upstream and we're only seeing it on certain AArch64 devices.

If you're unsure, this command should tell you the model number, cat /proc/cpuinfo | grep Hardware, please let me know what it says.

[dhuux]

i'm learning English so be patient with my English.

there is a patched Glibc for Termux thanks to @Maxython that really made it easy to run Linux AArch64 binaries on Termux unless the program has some hardcoded Standard paths or it's a statically linked binary that do networking stuff, you are good. maybe i'm wrong there. i'm really a newbie myself but that is what have seen so far. now for Rust you really can use Rustup to install the toolchains nightly, stable and the targets on Termux.

this method needs just little work and it's extremely easy:

just switch your Termux package manager to Pacman by switching to its bootstrap. or you can use Pacman without switching bootstraps. i would advice you to switch to it though. then as usual do:

$ pacman-key --init
$ pacman-key --populate
$ pacman -Syu

then install glibc and other important libs and tools
i don't know if Rust needs anything other than glibc and llvm-libs

$ pacman -S glibc
$ pacman -S llvm-glibc
$ pacman -S glibc-runner
$ pacman -S wget-glibc
$ pacman -S git-glibc
$ pacman -S gcc-glibc
$ pacman -S make-glibc
$ pacman -S cmake-glib

maybe there is another way to download them but that is how i do it.

now for glibc based binaries to run smoothly put unset LD_PRELOAD in your .bashrc file. or even better comment out this line:

export LD_PRELOAD=/data/data/com.termux/files/usr/lib/libtermux-exec.so

in your Terrmux login script. $PREFIX/bin/login

if you don't want to always termux-fix-shebang on your scripts you can always go back and uncomment it that line.

now get the rustup-init binary from the official site and place it in your home.

$ cd then

$ wget https://static.rust-lang.org/rustup/dist/aarch64-unknown-linux-gnu/rustup-init

now that the binary is is in your home. make it executable:
$ chmod +x rustup-init

now you need to patch it against the right dynamic linker/loader before you run it.

you either patch your binaries the manual way:

$ patchelf --set-interpreter $PREFIX/glibc/lib/ld-linux-aarch64.so.1 yourbinary 
$ patchelf --set-rpath $PREFIX/glibc/lib yourbinary

or you can use this script autopatchelf.zip that i found here check it up if you are a paranoia. i have no programming or scripting skills so if one of you could improve it for me i would appreciate that. it feels slow than it should have been but it does what it was supposed to do perfectly really. what i like about it is that: it checks the binary's dependencies before patching it, and tells you what shared object wasn't found. it also patches all the binaries in the sub dirs recursively.

EDIT: i forgot this line:

export libs=/data/data/com.termux/files/usr/glibc/lib

put this in your ~/.bashrc for the script to search for the libs.

put the script in your $PREFIX/bin dir and use it like this. make it executable first if it's not.

$ autopatchelf yourbinary

recursicely:

$ autopatchelf ./bin

non-recursively:

$ autopatchelf --no-recurse ./bin

after you patch it run the rustup installer tool.
$ ./rustup-init

choose your option from the prompt.
choose the default 1<. you can install nightly version later and the targets you want.

when finshed stable toolchain is ready. now simply patch the bianries by using the script. first patch rustup.

$ autopatchelf ~/.cargo/bin/rustup

now go to the toolchain directory.

$ cd ~/.rustup/toolchains/stable-aarch64-unknown-linux-gnu

copy lib/ to glibc dir for shared libs to be ready for the binaries.

$ cp -r lib/ $PREFIX/glibc

and now patch the binaries in ./bin and ./libexec

$ autopatchelf ./bin

and

$ autopatchelf ./libexec

now copy this dirs over their respective dirs in glibc dir

$ cp -r lib/ share/ libexec/ share/ etc/ $PREFIX/glibc

that is done. now install the nightly version and do the same.
$ rustup toolchain install nightly

clang and gdb are not available in the gpkg repo i think. but Termux packages repo has them so.

if anything seems confusing or i wrote it wrong i will try to make it clear, though my English is not good.

[sylirre]

in your Terrmux login script. $PREFIX/bin/login

login will be overwritten on the next update of termux-tools package. Don't edit everything in bin directory.

Create $PREFIX/etc/termux-login.sh with unset LD_PRELOAD if you need to have it disabled before shell was started. Otherwise add it into ~/.bashrc.

[dhuux]

thanks for pointing this out @sylirre. i will do this from now on. i have seen your Reddit comment.

[Kreijstal]

how did you fix this error

~/l $ cargo r
   Compiling l v0.1.0 (/data/data/com.termux/files/home/l)
warning: hard linking files in the incremental compilation cache failed. copying files instead. consider moving the cache directory to a file system which supports hard linking in session dir `/data/data/com.termux/files/home/l/target/debug/incremental/l-1os6co7mgzkdg/s-grusn3khn8-mzo5l8-working`

error: linking with `cc` failed: exit status: 1
  |
  = note: LC_ALL="C" PATH="/data/data/com.termux/files/home/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/bin:/data/data/com.termux/files/home/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/bin/:/data/data/com.termux/files/home/.cargo/bin:/data/data/com.termux/files/usr/bin" VSLANG="1033" "cc" "/data/data/com.termux/files/usr/tmp/rustc1Si7vA/symbols.o" "/data/data/com.termux/files/home/l/target/debug/deps/l-f9ae997284833588.376f1mn2llboxeyn.rcgu.o" "/data/data/com.termux/files/home/l/target/debug/deps/l-f9ae997284833588.3ettotjzqqbxw8xi.rcgu.o" "/data/data/com.termux/files/home/l/target/debug/deps/l-f9ae997284833588.48lwtuer6x7hofva.rcgu.o" "/data/data/com.termux/files/home/l/target/debug/deps/l-f9ae997284833588.4rcibw9esqp3zi8a.rcgu.o" "/data/data/com.termux/files/home/l/target/debug/deps/l-f9ae997284833588.4ro5y06t664kf29m.rcgu.o" "/data/data/com.termux/files/home/l/target/debug/deps/l-f9ae997284833588.brf268wepareda2.rcgu.o" "/data/data/com.termux/files/home/l/target/debug/deps/l-f9ae997284833588.3l84xgn1pozjji3s.rcgu.o" "-Wl,--as-needed" "-L" "/data/data/com.termux/files/home/l/target/debug/deps" "-L" "/data/data/com.termux/files/home/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "/data/data/com.termux/files/home/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libstd-84a09a48c3c6b54d.rlib" "/data/data/com.termux/files/home/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libpanic_unwind-c4ba3b236094d399.rlib" "/data/data/com.termux/files/home/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libobject-f9e04315aa430975.rlib" "/data/data/com.termux/files/home/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libmemchr-86ceeb5a9461246a.rlib" "/data/data/com.termux/files/home/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libaddr2line-44e64fcc20198442.rlib" "/data/data/com.termux/files/home/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libgimli-81eab08a224264bd.rlib" "/data/data/com.termux/files/home/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/librustc_demangle-8503a7b343f9837e.rlib" "/data/data/com.termux/files/home/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libstd_detect-fd8f9b0cfb9d7f01.rlib" "/data/data/com.termux/files/home/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libhashbrown-3790608017fa6e94.rlib" "/data/data/com.termux/files/home/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/librustc_std_workspace_alloc-c269f00eee9a30c3.rlib" "/data/data/com.termux/files/home/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libminiz_oxide-027c36d6d5bc08c1.rlib" "/data/data/com.termux/files/home/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libadler-83df4cc4cab6e709.rlib" "/data/data/com.termux/files/home/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libunwind-1c190e29f4f5cdb7.rlib" "/data/data/com.termux/files/home/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libcfg_if-b0060629c3d36754.rlib" "/data/data/com.termux/files/home/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/liblibc-81302654bc981630.rlib" "/data/data/com.termux/files/home/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/liballoc-c9884d527648962c.rlib" "/data/data/com.termux/files/home/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/librustc_std_workspace_core-124b61123a46b4e8.rlib" "/data/data/com.termux/files/home/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libcore-fc56b68ff40e402d.rlib" "/data/data/com.termux/files/home/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libcompiler_builtins-1284ae25723df48d.rlib" "-Wl,-Bdynamic" "-lgcc_s" "-lutil" "-lrt" "-lpthread" "-lm" "-ldl" "-lc" "-Wl,--eh-frame-hdr" "-Wl,-z,noexecstack" "-L" "/data/data/com.termux/files/home/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib" "-o" "/data/data/com.termux/files/home/l/target/debug/deps/l-f9ae997284833588" "-Wl,--gc-sections" "-pie" "-Wl,-z,relro,-z,now" "-nodefaultlibs" "-L/data/data/com.termux/files/usr/glibc/lib"
  = note: ld.lld: error: unable to find library -lgcc
          cc: error: linker command failed with exit code 1 (use -v to see invocation)


warning: `l` (bin "l") generated 1 warning
error: could not compile `l` (bin "l") due to previous error; 1 warning emitted

im compiling a simple hello world by doing cargo new

--
Edit:
I don't know what I am doing wrong but I used this to force the linker to link.
export RUSTFLAGS="-C link-arg=-L$PREFIX/glibc/lib -L$PREFIX/glibc/lib/gcc/aarch64-linux-gnu/13.2.0/"
now I get
` = note: ld.lld: error: undefined symbol: __libc_init
>>> referenced by crtbegin.c
>>> /data/data/com.termux/files/usr/lib/crtbegin_dynamic.o:(_start_main)
cc: error: linker command failed with exit code 1 (use -v to see invocation)

warning: l (bin "l") generated 1 warning
error: could not compile l (bin "l") due to previous error; 1 warning emittedoncargo r`

[DinkyTrady]

@dhuux
autopatchelf permission denied any explanation? And some package need for autopatchelf like file and libelf for libelf-glibc i don't know why that can't exectued

[Kreijstal]

@dhuux autopatchelf permission denied any explanation? And some package need for autopatchelf like file and libelf for libelf-glibc i don't know why that can't exectued

you need to run it from tmux directory, no storage, and obviously use chmod for it , or simply run "bash autopatch"

[Kreijstal]

~/l $ autopatchelf ~/.cargo/bin/rustup
Auto patching ELF binary: /data/data/com.termux/files/home/.cargo/bin/rustup
Setting RPATH to: /data/data/com.termux/files/usr/glibc/lib:/data/data/com.termux/files/usr/glibc/lib:/data/data/com.termux/files/usr/glibc/lib:/data/data/com.termux/files/usr/glibc/lib:/data/data/com.termux/files/usr/glibc/lib:/data/data/com.termux/files/usr/glibc/lib
Changing program interpreter to: /data/data/com.termux/files/usr/glibc/lib/ld-linux-aarch64.so.1
~/l $ cargo r
   Compiling l v0.1.0 (/data/data/com.termux/files/home/l)
warning: hard linking files in the incremental compilation cache failed. copying files instead. consider moving the cache directory to a file system which supports hard linking in session dir `/data/data/com.termux/files/home/l/target/debug/incremental/l-1os6co7mgzkdg/s-grvf6d5lwc-inxwa0-working`

error: linking with `cc` failed: exit status: 1
  |
  = note: LC_ALL="C" PATH="/data/data/com.termux/files/home/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/bin:/data/data/com.termux/files/home/.cargo/bin:/data/data/com.termux/files/usr/bin" VSLANG="1033" "cc" "/data/data/com.termux/files/usr/tmp/rustcfoY42F/symbols.o" "/data/data/com.termux/files/home/l/target/debug/deps/l-f9ae997284833588.376f1mn2llboxeyn.rcgu.o" "/data/data/com.termux/files/home/l/target/debug/deps/l-f9ae997284833588.3ettotjzqqbxw8xi.rcgu.o" "/data/data/com.termux/files/home/l/target/debug/deps/l-f9ae997284833588.48lwtuer6x7hofva.rcgu.o" "/data/data/com.termux/files/home/l/target/debug/deps/l-f9ae997284833588.4rcibw9esqp3zi8a.rcgu.o" "/data/data/com.termux/files/home/l/target/debug/deps/l-f9ae997284833588.4ro5y06t664kf29m.rcgu.o" "/data/data/com.termux/files/home/l/target/debug/deps/l-f9ae997284833588.brf268wepareda2.rcgu.o" "/data/data/com.termux/files/home/l/target/debug/deps/l-f9ae997284833588.3l84xgn1pozjji3s.rcgu.o" "-Wl,--as-needed" "-L" "/data/data/com.termux/files/home/l/target/debug/deps" "-L" "/data/data/com.termux/files/home/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "/data/data/com.termux/files/home/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libstd-84a09a48c3c6b54d.rlib" "/data/data/com.termux/files/home/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libpanic_unwind-c4ba3b236094d399.rlib" "/data/data/com.termux/files/home/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libobject-f9e04315aa430975.rlib" "/data/data/com.termux/files/home/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libmemchr-86ceeb5a9461246a.rlib" "/data/data/com.termux/files/home/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libaddr2line-44e64fcc20198442.rlib" "/data/data/com.termux/files/home/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libgimli-81eab08a224264bd.rlib" "/data/data/com.termux/files/home/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/librustc_demangle-8503a7b343f9837e.rlib" "/data/data/com.termux/files/home/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libstd_detect-fd8f9b0cfb9d7f01.rlib" "/data/data/com.termux/files/home/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libhashbrown-3790608017fa6e94.rlib" "/data/data/com.termux/files/home/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/librustc_std_workspace_alloc-c269f00eee9a30c3.rlib" "/data/data/com.termux/files/home/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libminiz_oxide-027c36d6d5bc08c1.rlib" "/data/data/com.termux/files/home/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libadler-83df4cc4cab6e709.rlib" "/data/data/com.termux/files/home/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libunwind-1c190e29f4f5cdb7.rlib" "/data/data/com.termux/files/home/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libcfg_if-b0060629c3d36754.rlib" "/data/data/com.termux/files/home/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/liblibc-81302654bc981630.rlib" "/data/data/com.termux/files/home/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/liballoc-c9884d527648962c.rlib" "/data/data/com.termux/files/home/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/librustc_std_workspace_core-124b61123a46b4e8.rlib" "/data/data/com.termux/files/home/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libcore-fc56b68ff40e402d.rlib" "/data/data/com.termux/files/home/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libcompiler_builtins-1284ae25723df48d.rlib" "-Wl,-Bdynamic" "-lgcc_s" "-lutil" "-lrt" "-lpthread" "-lm" "-ldl" "-lc" "-Wl,--eh-frame-hdr" "-Wl,-z,noexecstack" "-L" "/data/data/com.termux/files/home/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib" "-o" "/data/data/com.termux/files/home/l/target/debug/deps/l-f9ae997284833588" "-Wl,--gc-sections" "-pie" "-Wl,-z,relro,-z,now" "-nodefaultlibs"
  = note: ld.lld: error: unable to find library -lgcc_s
          cc: error: linker command failed with exit code 1 (use -v to see invocation)


warning: `l` (bin "l") generated 1 warning
error: could not compile `l` (bin "l") due to previous error; 1 warning emitted

what is going on?

[Kreijstal]

I modified autopatch elf so it does not rpath the same path multiple times, aka it deletes duplicates

autoPatchBinary()
{
    local binary="$1"
    local searchPathVariable="$2"

    echo "Auto patching ELF binary: $binary" >&2

    local binaryArch=$(guessArch "$binary")

    # For each needed library, look for a package that provides and compose an RPATH string for all the paths

    local archSpecificSearchPathVariable="${searchPathVariable}_${binaryArch}"

    local neededLibraries=$(patchelf --print-needed "$binary")
    local searchLibraryPaths="$(dirname "$binary"):${!archSpecificSearchPathVariable}:${!searchPathVariable}"
	
	declare -A uniqueLibPaths
	
    local rpath=

    for lib in $neededLibraries
    do
        local foundLibPath=

        if [ -e "$(dirname "$binary")/$lib" ]
        then
            foundLibPath="$(dirname "$binary")"
        else
            IFS=':'
            for libPath in $searchLibraryPaths
            do
                if [ -e "$libPath/$lib" ]
                then
                    foundLibArch=$(guessArch "$libPath/$lib")

                    if [ "$foundLibArch" = "$binaryArch" ]
                    then
                        foundLibPath="$libPath"
                    else
                        echo "WARNING: candidate library found but has architecture: $foundLibArch, while the binary has: $binaryArch" >&2
                    fi
                    break
                fi
            done
            unset IFS
        fi

        if [ "$foundLibPath" = "" ]
        then
            echo "No package found that provides library: $lib" >&2
            exit 1
        else
            # Add the library path to the associative array if it's not already present
            if [ -z "${uniqueLibPaths[$foundLibPath]}" ]; then
                uniqueLibPaths[$foundLibPath]=1
                rpath="$rpath${rpath:+:}$foundLibPath"
            fi
        fi
    done

    # Patch the binary's RPATH to allow it to find the needed libraries

    if [ "$rpath" != "" ]
    then
        echo "Setting RPATH to: $rpath" >&2
        patchelf --set-rpath "$rpath" "$binary"
    fi

    # Check whether the binary requires a program interpreter, and if so, patch it

    if readelf -l "$binary" | grep -q "Requesting program interpreter:"
    then
        IFS=':'
        for libPath in $searchLibraryPaths
        do
            local interpreterLibrary=$(basename $(patchelf --print-interpreter "$binary"))
            local interpreterSubstitute="$libPath/$interpreterLibrary"

            if [ -e "$interpreterSubstitute" ]
            then
                echo "Changing program interpreter to: $interpreterSubstitute" >&2
                patchelf --set-interpreter "$interpreterSubstitute" "$binary"
                local interpreterPatched=1
                break
            fi
        done
        unset IFS

        if [ "$interpreterPatched" != "1" ]
        then
            echo "Cannot find substitute interpreter: '$interpreterSubstitute'. Did you provide a compatible version of libc in the library search paths?" >&2
            exit 1
        fi
    fi
}

[Maxython]

@dhuux, I just have two questions about your guide about installing rust on glibc in Termux:

1. why didn't you run a special shell from glibc-runner (grun --shell)?
2. why don't you use the --set flag in glibc-runner to configure the binary (more details). I think that this step you are describing is very complicated due to the installation of another tool.

[dhuux]

@dhuux, I just have two questions about your guide about installing rust on glibc in Termux:

1. why didn't you run a special shell from glibc-runner (grun --shell)?

i don't know how to explain this well but binaries (processes) did't work well with one another under the special shell when the binaries are in other dirs than $GLIBC_REFIX/bin.

i think it was gradle that couldn't spawn jvm without unsetting LD_PRELOAD in the login file. i mean without unsetting LD_PRELOAD for the hidden processes things wouldn't work smoothly under the hood. maybe i'm wrong there and i was doing it wrong.

2. why don't you use the --set flag in glibc-runner to configure the binary (more details). I think that this step you are describing is very complicated due to the installation of another tool

i found autopatchelf jdk-20.0.2/ to be
easier than:

for i in jdk-20.0.2/bin/*; do
    grun --set $i
done 

but that is not all. it won't only patch the binaries in the bin folder but also the ones in the lib folder and all the sub folders if there are any. it also checks the architecture of the binary file, looks for its depencies in the paths you set and tells you which shared object is missing from that path. i mean it's just a small script but i find it handy.

i mean get the binary file from somewhere, run autopatchelf on it, and ./file without grun runner, right? yes i know i have to termux-fix-shegang on some scripts manually sometimes.

thanks for your work my friend.

[dhuux]

warning: l (bin "l") generated 1 warning
error: could not compile l (bin "l") due to previous error; 1 warning emitted

what is going on?

never encountered this problem. i'm really not skilled at these things. but are you sure you did:

autopatchelf ~/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/bin/

as well?

i tried your example and other random tools, i haven't seen any problems yet.

[dhuux]

i have just decided to learn rust as my first language by making little tui scripts and then converting them into little gui apps so i don't get bored easily. now i set egui/eframe up, then built the project's example. the web part is working wonderfully, but the native executable needs glibc based mesa compiled for Termux for the graphics to show up. probably i'm using the wrong vocabs here. hhhh

i can't use a glibc based program with the Termux's bionic mesa drivers, can i?

i tested it with the Archlinux's ARM one. but as you can see, i can only run the binary under proot by using Termux-chroot script for setting up the proot environment.

without Termux-chroot, the executable would throw bad system call because of the wrong mesa linked against. i hope @Maxython is working on it.

[dhuux]

my device is old. a 6 year old device and it's not that bad when building/compiling. imagine people with the modern high end devices!

[finagolfin]

imagine people with the modern high end devices!

The latest high-end Android chips are basically laptop chips, as the Snapdragon 8 Gen chips benchmark faster than all core i5 laptop chips and the low-end core i7 laptop chips that have the same number of cores, while using much less electrical power. Apple's M-series AArch64 chips, which come in all the high-end iPads now, benchmark faster than all x86_64 laptop chips and many x86_64 desktop chips too, while using a fraction of the electrical power. This is why many server vendors are switching over to AArch64 too, like Amazon and their in-house designed Graviton AArch64 chip that you can rent on AWS.

X86_64 vendors like Intel and AMD are dead men walking, only a matter of time, ie porting most worthwhile software over from x86_64 to AArch64.

[dhuux]

and they are only getting better.
ZTE's flagship phone the

• Snapdrog 8 gen 3
• ROM 1T
• RAM 24 GB version

could be a good deal for someone like me. it would be much cheaper than Samsung's and Apple's flagships but i can't find cheap and good at the same time things here unfortunately.

maybe in 10 years there will be a new method other than the current EUV lithography that mass produces extremely cheap and powerful chips then we can have Android/Fuchsia/Harmony/Linux phones which are capable of building LLVM+CLANG from source in 15 minutes and i will finally buy these powerful phones under $300 here in Somalia.

it seem giants are embracing Arm Architecture for good. too bad we can't run Arm64/AArch64-Darwin binary file on a linux-AArch64 computer.

[finagolfin]

gradle build failed ninja part

What's the error?

have you ever used NDK in a linux-Aarch64 computer?

Not the official NDK, only our patched ndk-sysroot in Termux.

[dhuux]

What's the error?

it was weeks ago. i couldn't understand what i was missing. so i deleted the whole thing. i will try it again when i free some storage space on my phone. here is a screenshot i took of it that day.

now i suspect it was the ninja itself was it? i copied the binary from proot archlinux distro then patched it and put it there. how do i test it if ninja is working right?

[dhuux]

when i changed it to the path of the Termux NDK the build had completed successfully.

[finagolfin]

now i suspect it was the ninja itself was it?

It looks like the issue is compiling C++ code, the error: format specifies type.... Does that sample compile fine on linux x86_64?

If so, you can try it again now in Termux and open a separate issue with any problems you see, which someone may help you with.

[dhuux]

It looks like the issue is compiling C++ code, the error: format specifies type.... Does that sample compile fine on linux x86_64?

when i switched to the Termux ndk it compiled successfully. so the problem has something to do with the llvm toolchain i replaced in the official NDK. maybe when i replaced the toolchain i was supposed to tell the NDK that i replaced the toolchain shipped in the NDK with a new one. but i don't know how.

[dhuux]

If so, you can try it again now in Termux and open a separate issue with any problems you see, which someone may help you with.

i will do that. thanks.

[Maxython]

@dhuux

i don't know how to explain this well but binaries (processes) did't work well with one another under the special shell when the binaries are in other dirs than $GLIBC_REFIX/bin.

This can be fixed quite easily by adjusting the PATH value:

export PATH="~/.cargo/bin:~/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/bin:$PATH"

i think it was gradle that couldn't spawn jvm without unsetting LD_PRELOAD in the login file. i mean without unsetting LD_PRELOAD for the hidden processes things wouldn't work smoothly under the hood. maybe i'm wrong there and i was doing it wrong.

The LD_PRELOAD value is the main reason why glibc binaries cannot run on Termux because it points to a bionic library, and as a result a “conflict” occurs.

i found autopatchelf jdk-20.0.2/ to be easier than:

I think I know how to improve glibc-runner. Maybe this simplifies the setup, but I'm not sure that it configures some binaries correctly. For example, the rustc binary from ~/.rustup needs some libraries that are located in ~/.rustup/***/lib. Although this is of course all my opinion and I have never used autopatchelf, I was able to set everything up with the power of glibc-runner and with patchelf.

I also tested eframe_template and everything works for me. Are you using the latest version of glibc?

[dhuux]

firstly i wanted to say i'm really grateful for what you developers and nice project maintianers do for us (newbies). you made the android phones useful and fun for a lot of people.

This can be fixed quite easily by adjusting the PATH value:

rustup installer tool rustup-init takes care of the rustup environment variable and rustup takes care of the rest so i don't need to set up anything either $HOME/.cargo/env sourced in .bashrc.

i was talking about gradle and glibc based openjdk.
try to set that up under glibc-runner. gradle failed to run jvm, though java is correctly set and available. but when i unset LD_PRELOAD permenantly it did work and if i have to unset LD_PRELOAD every time i'm using java and gradle together what is the point of glibc-runner. i mean, i can still use glibc programs and other glibc based programs in other places without glibc-runner after adding them to path and there will be no bionic and glibc library conflicts.

rustc binary from ~/.rustup needs some libraries that are located in ~/.rustup/***/lib

ldconfig solved that for me. i added the three toolchains (stable, nighly and beta) paths to .bashrc for the autopatchelf and ld.so.conf for the linker. so i don't have to move shared objects around. i can unisntall and reinstall the toolchains as much as i want without copying lib/*.so to $PREFIX/glibc/lib. i would only do: autopatchelf .rustup/toolchains/thetoolchain once when ever i install or reinstall a new toolchain and that is it.

I also tested eframe_template and everything works for me.

web app is fine. but the native app wouldn't run without glibc based mesa. if you did run it under termux without compiled glibc based mesa for Termux. how? if you built the mesa library and have it on your phone please release it.

[ly132806]

@dhuux When I run ./rustup-init I get the error: error while loading shared libraries: libdl.so: cannot open shared object file: No such file or directory
How can I do this?

[dhuux]

@ly132806 do nano $PREFIX/etc/termux-login.sh.
put this line unset LD_PRELOAD. open new session and you are okay.