-
Notifications
You must be signed in to change notification settings - Fork 87
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
I want to compile an application that does not contain any dynamic libraries #176
Comments
This not that easy. You need at least compile libudev statically. And solve some other problem |
For |
All necessary dependency packages have been installed apt install libusb–dev libudev–dev linux-headers-$ (uname -r) rusb = { version = "0.9.2"} rusb = { version = "0.9.2",features = ["vendored"]} |
All problems lie in the use of musl. As I said earlier, building under musl is not such an easy task. You need to properly prepare the build environment. And standard packages will not suit you. Another option is to try to find a way to build libusb-1.0 under musl. I tried searching but didn't find any success story. |
Solved (partially?)The answer is to create symlinks in /usr/lib/$ARCH-linux-musl/ that point to the files you need from /usr/include/ For example:
After doing this, you will be able to compile using cargo with Here's an example from the rayhunter project: $ cargo build --bin serial --target x86_64-unknown-linux-musl --release
Compiling libusb1-sys v0.6.4
Compiling rusb v0.9.3
Compiling serial v0.1.0 (/home/user/rayhunter/serial)
Finished `release` profile [optimized] target(s) in 2.00s
$ ldd target/x86_64-unknown-linux-musl/release/serial
statically linked A hat tip to both @cosoc and @a1ien for their comments. 🙏 It helped me make progress towards solving a mostly-unrelated issue over here: EFForg/rayhunter#93 Now that the rust code compiles statically, I just have to figure out why the program fails to initialize libusb... Doh! My best guess is that because libusb depends on libudev, we need to compile libudev statically with musl, then manually compile libusb in the same manner, and then we can get cargo to statically link in the resulting libusb file. Maybe a rust developer will be able to take a look at this and build on my work, just as I built on those earlier in this thread? How I tracked it downI'm including this section to help others understand how I figured out how to solve the missing headers issue. No need to read it if you just want to know the conclusion (posted in the section above). I found it helpful to attempt to compile libusb with musl-gcc outside of rust.
This results in an error: However, the header file is in the location where I would expect it... $ ls /usr/include/libudev.h
/usr/include/libudev.h Running
Creating symlinks between where musl-gcc is looking and where the files actually live resolved the problem with the cargo build. It also resolved the immediate problem with ./configure and the next error ( $ sudo ln -s /usr/lib/x86_64-linux-gnu/libudev.so /usr/lib/x86_64-linux-musl
$ sudo ln -s /usr/lib/x86_64-linux-gnu/libudev.so.1 /usr/lib/x86_64-linux-musl
$ sudo ln -s /usr/lib/x86_64-linux-gnu/libudev.so.1.7.10 /usr/lib/x86_64-linux-musl In retrospect, linking to this dynamically linked .so file is probably the mistake that is causing the library to fail to load in the statically compiled rust program. |
os info: debian11
Cargo.toml
test main function
build cmd
error
What am I going to do?
My Action Log
Successfully compiled!
But ldd cmd
My expected outcome is
ldd cmd
The text was updated successfully, but these errors were encountered: