I am trying to compile my Rust project with dynamic linking to reduce the size and provide .so (or .dll on Windows) files with the application just like Qt does for Android. I read Why are Rust executables so huge? and compiled with
cargo rustc -- -C prefer-dynamic
When I run my program, I get this error:
% target/debug/t_pro
target/debug/t_pro: error while loading shared libraries: libstd-a021829e87e39dcf.so: cannot open shared object file: No such file or directory
I got an answer on Reddit.
rustc --print=sysroot
In my case, the .so files are in /home/username/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib and .rlib are in /home/username/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib.
The libraries are installed wherever you chose to install Rust. I use rustup on macOS, so they are installed in ~/.rustup/toolchains/*whatever*/lib/ for me.
Use your operating system's tools to search for files of a specific name.
See also:
How to set the environmental variable LD_LIBRARY_PATH in linux
Related
Right now, I have a modified version of a open-source dependency library (mylib.a file) in my project and thus I have it statically linked via gcc command(s). I am getting the error that...
"statically linked applications require at runtime the shared libraries from the glibc version used for linking"
My translation: my static dependency library cannot dynamically use glibc; it must also be compiled and dynamically linked. Thus, I'm trying to compile and statically link glibc.
I've gather that they would need to be compiled, the *.a library placed in a folder within the project, the "-I//location//" added in for the include headers, and the "-L//location//" added in for the libraries themselves.
But, for the question itself...
How to you compile glibc (32-bit and 64-bit)?
Through open-source research, I've found this link and I have cloned the repo but I cannot find any documentation on how to actually compile it.
git clone git://sourceware.org/git/glibc.git
Any thoughts or suggestions are welcomed.
My translation: my static dependency library cannot dynamically use glibc; it must also be compiled and dynamically linked. Thus, I'm trying to compile and statically link glibc.
As n.m. pointed out, your translation is wrong.
You are trying to link a fully static executable, and GLIBC is warning you that such executable will not run correctly on any machine with a different version of GLIBC installed.
Instead of trying to build a fully-static executable, build it such that it uses libc.so.6 (you can still link mylib.a into such executable).
IF the reason you added -static to your link is that you have both libmylib.a and libmylib.so, and would like to link in the former instead of the latter, read this answer.
I am trying to cross-compile my Rust project on Mac OS to Linux using cargo build --target=x86_64-unknown-linux-musl.
I installed the binary for Linux + musl cross-compilation on mac using brew install FiloSottile/musl-cross/musl-cross as I would ideally want a standalone binary.
I also installed the target using rustup target add x86_64-unknown-linux-gnu
And I have the following in my .cargo/config:
[target.x86_64-unknown-linux-musl]
linker = "x86_64-linux-musl-gcc"
However, I ran into issues with 2 libraries - sqlite3 and pcap:
= note: /usr/local/Cellar/musl-cross/0.9.8/libexec/bin/../lib/gcc/x86_64-linux-musl/6.4.0/../../../../x86_64-linux-musl/bin/ld: cannot find -lsqlite3
/usr/local/Cellar/musl-cross/0.9.8/libexec/bin/../lib/gcc/x86_64-linux-musl/6.4.0/../../../../x86_64-linux-musl/bin/ld: cannot find -lpcap
collect2: error: ld returned 1 exit status
I was able to solve the sqlite3 linker issue by adding features = ["bundled"] to my Cargo.toml file (similar to what is described here - https://users.rust-lang.org/t/linker-cannot-find-lsqlite3/23230/18) as that likely built it from source (which was great) but when I tried doing the same with pcap, it gave the following error:
the package `myProject` depends on `pcap`, with features: `bundled` but `pcap` does not have these features.
After reading somewhere I also tried (with low hopes) of providing the path to the installed libpcap on mac using RUSTPATH='-L/...' cargo build ... but that resulted, of course in undefined symbol errors.
Any ideas how can I get past this issue and cross compile my Rust project into a statically linked binary on macos to run on linux?
Cross compilation does not magically take care of libraries. You cannot just say "I want musl" and have something take care of all your dependencies.
The error message you are seeing is telling you exactly this: it cannot find libsqlite3 and libpcap.
The reason the error for sqlite disappears is because your sqlite library has a bundled feature, which replaces the linking with a built-in sqlite client. This, however, also requests the pcap bundled feature, which does not exist.
You have two options:
If you do not mind the performance loss in the bundled sqlite client, change your feature definition to target the feature of the dependency requiring sqlite
If you want the raw library itself, you will have to compile it for musl
No matter what happens, you will need to cross-compile libpcap for musl with the default sysroot provided by your musl compiler. As this varies per library, you will need to consult the libpcap documentation. once you have done so, you should be able to use the -lpcap flag, and the error will resolve itself.
I've used
cargo install --git https://github.com/steveklabnik/rustbook.git
to install rustbook successfully, but when I run rustbook I get an error:
rustbook: error while loading shared libraries: librustdoc-c0dcaea09a16c7ec.so: cannot open shared object file: No such file or directory
But I can find out this .so file.
./.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/librustdoc-c0dcaea09a16c7ec.so
./.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustdoc-c0dcaea09a16c7ec.so
How can I let rustbook know the path to librustdoc-c0dcaea09a16c7ec.so?
rustc 1.16.0-nightly (4ecc85beb 2016-12-28)
rustdoc 1.16.0-nightly (4ecc85beb 2016-12-28)
rustup show:
Default host: x86_64-unknown-linux-gnu
nightly-x86_64-unknown-linux-gnu (default)
rustc 1.16.0-nightly (4ecc85beb 2016-12-28)
This appears to be a known issue with rustup (#350, #765), specifically around cargo-installed binaries that were compiled against the nightly toolchain. If your application requires nightly to even compile, there's not much you can do other than rustup run nightly myprogram. This will start the program with the appropriate environment.
If the application doesn't require nightly Rust, then install it using the stable toolchain.
List the directory containing your shared library into /etc/ld.so.conf, or make a symlink from a path already listed there, or from /usr/lib (/usr/local/lib would be preferable, but maybe you have to add it to the list in ld.so.conf, so this would be again case 1).
I am using autoconf gnu tools to build my product.
It generates both the shared as well as static library for any library where *.la is mentioned.
The issue is if you use .la to link your binary in Makefile.am.
It links with the dynamic library but when you use ldd to the binary, it says
"not a dynamic executable" although it links with shared library. I proved it by removing the shared library after the binary is built and then tried to run the binary. It didn't find the shared library and couldn't run.
Another question is how to put library in a specified location using Makefile.am direction ?
Looks like you run ldd on the wrapper scripts created by libtool. They are used to link uninstalled libraries with uninstalled executables. Real binaries are placed in .libs directory.
You can install a lib to some specific place in this way
mylibrary_LTLIBRARIES = libmylibrary.la
mylibrarydir = ${libdir}/my_plugins/
My build process consists of Qt's qmake Makefile generator and the typical make utility bundled with linux.
My application consists of a few shared libraries and the main application is linked against them.
How can I apply the typical linux versioning scheme on my libraries? (Use version 2 -> link against foo.so.2 that points to foo.so.2.y.z with an ldconfig generated link).
The answer doesn't have to be specific for my build process.
Your library should be named libfoo.so.2.y.z, with symlinks of libfoo.so.2 and libfoo.so both pointing to that. The library should be created using -soname libfoo.so.2 in the linker command line (or -Wl,-soname,libfoo.so.2 on the gcc command line).
Hope that helps!