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.

[Rob801130]

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

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

[pschmitt]

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.

Have been running the debs from the previous pipeline (1.68.1) run since yesterday. All good, installed fine and it works too. Thanks !

Installed the 1.68.2 debs just now. Installed fine:

$ dpkg -i *.deb
(Reading database ... 83990 files and directories currently installed.)
Preparing to unpack rust-docs_1.68.2_all.deb ...
Unpacking rust-docs (1.68.2) over (1.68.1-1) ...
Preparing to unpack rust-std-wasm32_1.68.2_all.deb ...
Unpacking rust-std-wasm32 (1.68.2) over (1.68.1-1) ...
Preparing to unpack rust_1.68.2_aarch64.deb ...
Unpacking rust (1.68.2) over (1.68.1-1) ...
Preparing to unpack rustc-dev_1.68.2_aarch64.deb ...
Unpacking rustc-dev (1.68.2) over (1.68.1-1) ...
Setting up rust (1.68.2) ...
Setting up rustc-dev (1.68.2) ...
Setting up rust-docs (1.68.2) ...
Setting up rust-std-wasm32 (1.68.2) ...
Processing triggers for man (1.14.6) ...
dpkg -i *.deb  28.78s user 64.32s system 87% cpu 1:45.98 total

And Cargo works too:

$ llvm-ar --version
LLVM (http://llvm.org/):
  LLVM version 16.0.0                                  Optimized build.
$ cargo --version
cargo 1.68.2
$ cargo build --release
Compiling proc-macro2 v1.0.51
   Compiling quote v1.0.23
   Compiling unicode-ident v1.0.6
   Compiling syn v1.0.109
   Compiling autocfg v1.1.0
   Compiling libc v0.2.139
   Compiling cfg-if v1.0.0
   Compiling memchr v2.5.0
   Compiling log v0.4.17
   Compiling pin-project-lite v0.2.9
   Compiling futures-core v0.3.26
   Compiling cc v1.0.79
   Compiling version_check v0.9.4
   Compiling once_cell v1.17.1
   Compiling pkg-config v0.3.26
   Compiling lock_api v0.4.9
   Compiling parking_lot_core v0.9.7
   Compiling slab v0.4.8
   Compiling futures-task v0.3.26
   Compiling bytes v1.4.0
   Compiling futures-channel v0.3.26
   Compiling smallvec v1.10.0
   Compiling scopeguard v1.1.0
   Compiling futures-sink v0.3.26
   Compiling tokio v1.25.0
   Compiling futures-util v0.3.26
   Compiling itoa v1.0.5
   Compiling parking_lot v0.12.1
   Compiling socket2 v0.4.7
   Compiling mio v0.8.6
   Compiling num_cpus v1.15.0
   Compiling signal-hook-registry v1.4.1
   Compiling standback v0.2.17
   Compiling futures-io v0.3.26
   Compiling openssl-sys v0.9.80
   Compiling pin-utils v0.1.0
   Compiling serde_derive v1.0.152
   Compiling indexmap v1.9.2
   Compiling tracing-core v0.1.30
   Compiling foreign-types-shared v0.1.1
   Compiling openssl v0.10.45
   Compiling serde v1.0.152
   Compiling fnv v1.0.7
   Compiling tracing v0.1.37
   Compiling http v0.2.9
   Compiling foreign-types v0.3.2
   Compiling hashbrown v0.12.3
   Compiling tinyvec_macros v0.1.1
   Compiling bitflags v1.3.2
   Compiling proc-macro-hack v0.5.20+deprecated
   Compiling thiserror v1.0.38
   Compiling httparse v1.8.0
   Compiling native-tls v0.2.11
   Compiling tinyvec v1.6.0
   Compiling percent-encoding v2.2.0
   Compiling try-lock v0.2.4
   Compiling openssl-probe v0.1.5
   Compiling form_urlencoded v1.1.0
   Compiling want v0.3.0
   Compiling http-body v0.4.5
   Compiling httpdate v1.0.2
   Compiling ryu v1.0.12
   Compiling tower-service v0.3.2
   Compiling unicode-bidi v0.3.10
   Compiling const_fn v0.4.9
   Compiling ucd-trie v0.1.5
   Compiling unicode-normalization v0.1.22
   Compiling time v0.2.27
   Compiling aho-corasick v0.7.20
   Compiling idna v0.3.0
   Compiling serde_json v1.0.93
   Compiling regex-syntax v0.6.28
   Compiling url v2.3.1
   Compiling atty v0.2.14
   Compiling encoding_rs v0.8.32
   Compiling mime v0.3.16
   Compiling base64 v0.21.0
   Compiling humantime v2.1.0
   Compiling termcolor v1.2.0
   Compiling ipnet v2.7.1
   Compiling regex v1.7.1
   Compiling tokio-macros v1.8.2
   Compiling futures-macro v0.3.26
   Compiling openssl-macros v0.1.0
   Compiling thiserror-impl v1.0.38
   Compiling pest v2.5.5
   Compiling time-macros-impl v0.1.2
   Compiling semver-parser v0.10.2
   Compiling futures-executor v0.3.26
   Compiling semver v0.11.0
   Compiling futures v0.3.26
   Compiling env_logger v0.8.4
   Compiling time-macros v0.1.1
   Compiling tokio-util v0.7.7
   Compiling tokio-native-tls v0.3.1
   Compiling h2 v0.3.15
   Compiling serde_urlencoded v0.7.1
   Compiling hyper v0.14.24
   Compiling hyper-tls v0.5.0
   Compiling reqwest v0.11.14
   Compiling timewarrior_jirapush v0.3.0 (/data/data/com.termux/files/home/.local/share/zinit/plugins/FoxAmes---timewarrior-jirapush)
    Finished release [optimized] target(s) in 3m 28s

[finagolfin]

clang package is also broken.

Installing it or using it? I will fix the install issue soon.

[s-cerevisiae]

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

It was something like "clang needs libllvm < 16.0.0". With apt --fix-broken install libllvm 16.0.0-1 and clang 16.0.0-1 were installed. They seems to be working fine currently. (Except that lld problem)

[2096779623]

Installing it or using it? I will fix the install issue soon.

When my clang/llvm version is still 15, it can be reproduced by the following command:

dpkg -i debs/rust_1.68.2*deb
pkg upgr -y

[finagolfin]

I have submitted a fix for the clang installation issue, #15883. Once I get my question answered on whether that's an adequate fix, I will merge it.

[joshcangit]

I hope this gets fixed soon. Wish to try Rust again some day.

[agnostic-apollo]

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.

In future when situations like these occur where packages need to be simultaneously updated, the infrastructure devs can be notified so that they disable the service in our server that removes old packages every 3hrs for the few days updates are being rolled out so that this doesn't occur again. But I guess that could significantly increase repo size for those few days, due to duplicate versions including those of unrelated big packages that are also updated during that time, which may be problematic to some mirrors. Currently, the repo size seems to be at almost 19GB. Probably possible to not remove specific packages only and their dependencies (and their dependents?), but would be more complex at benefit of less repo size increase.

[finagolfin]

Ideally, the rust maintainers would have their patch ready to go for when LLVM updates, then we only have an issue for 5-6 hours while the CI builds these large packages. However, lately there has not been a regular maintainer for rust and @xtkoba has stepped up with some rust updates, in addition to the dozens of other packages he's been updating.

Some people from the rust community will have to step up and maintain this package if they want it to keep working. Otherwise, it will keep breaking like this and the rest of us who don't use rust can't be expected to care.

[agnostic-apollo]

If time is usually 5-6hrs, then can just disable removal completely for that time, so that no one is affected, big unrelated updates could be paused too. I guess ping me, @Grimler91 or others who have server access next time.

Yeah, I agree, can't just keep putting stuff on @xtkoba, someone from rust community should step up, otherwise at least the community members shouldn't complain if breakages happen and aren't timely resolved.

[finagolfin]

An updated rust 1.68.2 built with LLVM 16 is now available, please update and report any issues that you see.

[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 emitted oncargo 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!