I have created a vscode environment based on this: GitHub - linuxserver/docker-openvscode-server
i installed the rust tools, and i can compile the program into a binary. However, when i copy it to an Ubuntu server and try to run it, i get this error:
./locutus: error while loading shared libraries: libssl.so.3: cannot open shared object file: No such file or directory
i have found one topic on this forum in regards to libssl.so.3 but that offered no solution. I was under the impression that it was a "compile once, run anywhere" kind of idea. i have created a few small programs, and they do indeed work everywhere else, from the same vscode environment to a Ubuntu server.
You need to compile for the
musl target to have "run anywhere".
Other linux distros (
gnu targets in Rust) depend on dynamic linking, which makes your executables dependent on specific packages installed on the specific operating system.
openssl-sys and other openssl-dependent crates have
vendored-openssl Cargo feature that you can enable and this usually helps with this particular dependency.
cargo deb to package executables in a Debian/Ubuntu-preferred way, which will also ensure that required dependencies are installed.
That's only true on Linux if you don't use any C code (except for GLibC). Unfortunately dynamic linking situation on Linux is even worse than Dll Hell that used to plague Windows was.
Thus if you step out of Rust and try to invoke C libraries… you are in trouble.
There are ways to fix that, but it's not “compile once, run anywhere”.
thank you both for answering
the vendored-ssl step gets me further, then it stops at:
./locutus: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by ./locutus)
./locutus: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./locutus)
./locutus: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by ./locutus)
I am currently downloading an older docker environment for vscode, one that equals the OS on the server im trying to run my program on. if that works, i'll be happy to learn more about the whole "compile once run anywhere" stuff i obviously need to deal with
Rust is not a VM or a scripting language, so Rust programs are exposed to whatever the OS requires. Ubuntu/Debian is not designed to support "compile once run anywhere". It supports "compile for this particular glibc and set of installed deb packages, and it won't run anywhere else". If you make executables directly for these distros, you have these distros' problems.
Practical solution is to not build for Debian/Ubuntu.
*-linux-gnu targets of Rust are for using the gnu glibc, not for bypassing it. But when you use the gnu glibc, you will have glibc-related problems. Instead, use a MUSL-based distro or cross-compile to one:
When compiling a program against the glibc libc implementation, the version against which it was linked is recorded in the executable. Any attempt to run it on a system with an older glibc version will fail with the error you mentioned. In your case the system you are compiling on has glibc 2.34, but the system you are trying to run it on has a glibc version less than 2.32. The only options you have unfortunately are compiling on a system with an older glibc version or statically linking against musl instead. Rustc itself is built on CentOS 7 to allow running it on systems with glibc 2.17 or newer.
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.