I often run into issues with glibc versions on the target machine is there anything i can do to prevent that ?
You can compile with the musl libc instead. It is statically linked.
How can i exactly do that ? or is there any way i can define which version of libc is used on compilation ? currently libc is required by a crate i use which uses curl and thats the only place libc is used so far afaik
You specify it in the target. Many rust targets use musl (it will be in the target name).
Something like cargo build --target pick-your-own-target-here
1 Like
i will try that right now hopefully it will work out, thanks.
Rust std code will link to libc too. The only real way to control which glibc symbol versions you link is to build with your target version in the first place. Or avoid glibc with musl, but then make sure you aren't linking anything else external that uses glibc.
1 Like
thats the weird thing. i am building in the rust docker container which runs on ubuntu and im deploying to ubuntu and still having issues for some reason
this is a very common problem distributing binaries on linux, your solutions are basically:
- use static linking (with musl libc as suggested tends to be the best option, statically linking against glibc has some problems)
- build on a system with the lowest version of libc you want to support
- use something like flatpak or snap that packages the application and handles glibc compatibility
2 Likes
The fact that it's Ubuntu is less important than the actual glibc versions involved. If the rust docker container is built on a newer Ubuntu release than your target, you may still get unwanted glibc symbol versions.
i will try musl as everyone suggested now lets see how it will go
If you build with cargo-deb, it will add Depends: libc6 (>= 2.24) (with the right version) to your .deb metadata, so at least the mismatch will be clearly communicated when installing the package.
3 Likes
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.