My executable Rust crate uses a native library libfoo.a which depends on a shared library libbar.so, but does not expose it at all.
My Rust FFI uses the methods from libfoo, so I defined a link attribute on my extern code::
#[link(name="foo", kind="static")]
extern "C"{
pub fn do_foo();
}
and my build.rs included from Cargo.toml using build="build.rs"
fn main() {
let libs = &[(Some("../libs/foo/1.0/"), "static=foo"), // use ../libs/foo/1.0/libfoo.a
(None, "bar")]; // use libbar.so using LD_LIBRARY_PATH
for &(ref m_path, ref lib) in libs {
if let &Some(static_path) = m_path {
println!("cargo:rustc-link-search={}", &static_path);
}
println!("cargo:rustc-link-lib={}", &lib);
}
}
which outputs
cargo:rustc-link-search=../libs/foo/1.0/
cargo:rustc-link-lib=static=foo
cargo:rustc-link-lib=bar
Theoretically, I expect Rust to link against libfoo.a and libbar.so. The problem is that rustc does not even try to acknowledge libbar.
cargo build --debug ends with
/home/author/src/foo/foo.c:21: undefined reference to 'bar_do_stuff'
collect2: error: ld returned 1 exit status
When I inspect the linker command, there is an -L ../libs/foo/1.0 argument, as well as -l foo, but there is no trace of -l bar !
If I manually add the -l bar to cc, it builds (and runs) just fine.
Could you let me know what I am missing? Should I create an FFI binding for libbar even though I don't use it in Rust and it is not exposed from libfoo's API?
The issue is a conflict between the #[link] attribute in the FFI definition and the output of the build.rs build script.
It would seem that the #[link] attribute is instructing rustc to ignore the cargo:rustc-link-* instructions.
The fix was as simple as removing the #[link] attribute.
Related
When we compile a c file using gcc test.c -o test.
We can get the binary file as test.
But while running a file using cargo run test.rs in rust.
can we get the binary like we got in the C program?
The original hello.c file:
void main() {
// printf() displays the string inside quotation
printf("Hello, World!");
}
The rust program:
extern "C" {
fn printf(_: *const libc::c_char, _: ...) -> libc::c_int;
}
unsafe fn main_0() {
// printf() displays the string inside quotation
printf(b"Hello, World!\x00" as *const u8 as *const libc::c_char);
}
pub fn main() { unsafe { main_0() } ::std::process::exit(0i32); }
When using cargo it compiles and runs perfectly.
└─$ cargo run hello.rs
Compiling Rust_testing v0.1.0 (/home/pegasus/Documents/Rust_testing)
warning: crate `Rust_testing` should have a snake case name
|
= note: `#[warn(non_snake_case)]` on by default
= help: convert the identifier to snake case: `rust_testing`
warning: `Rust_testing` (bin "Rust_testing") generated 1 warning
Finished dev [unoptimized + debuginfo] target(s) in 0.17s
Running `target/debug/Rust_testing hello.rs`
Hello, world!
Here's my Cargo.toml file:
[package]
name = "Rust_testing"
version = "0.1.0"
edition = "2021"
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
[dependencies]
libc = "0.2"
I have a rust program named hello.rs.
The program is I'm unable to compile it using rustc. I generated the hello.rs using c2rust online transpiler. But if I use cargo run hello.rs the program runs smoothly.
while using rustc new.rs -o test,
I can get the x86 test binary.
How to get similar kind of file while using the cargo run new.rs?
I looked into the target/debug directory.
But there are so many directories and so many files there. How to know which on is created for which .rs file?
┌──(pegasus㉿pegasus)-[~/Documents/Rust_testing/target/debug]
└─$ ls
build deps examples incremental Rust_testing Rust_testing.d
If you do cargo build, you will find the binary in target/debug/. If you build in release via cargo build --release, you will find it in target/release/.
Be aware that cargo run hello.rs does not compile hello.rs. It will always compile src/main.rs. hello.rs will be passed to the compiled program as a command line argument.
How to know which on is created for which .rs file?
There isn't one file for one .rs file. If your crate is a binary crate, then there will be exactly one executable with the name of your crate. In your case it's Rust_testing. You can run it with ./target/debug/Rust_testing, or copy it somewhere else and execute it directly.
You can add multiple binaries per crate by putting them in the src/bin folder. For example, if you put your hello.rs file in src/bin and then execute cargo build --all, it will create a target/debug/hello executable that you can run.
For more information about cargo's folder layout, read the cargo documentation.
If you are new to Rust, I highly recommend reading the Rust book. It will guide you through how to use rustup, rustc and cargo step by step.
I'd like to run a one off rust "script" without going through creating a cargo project for a single run (since I am providing this script to colleagues).
Ideally I could build directly with the command line avoiding creating cargo projects etc.
for instance:
use serde_json::Value;
use some_private_packege_i_own_locally_in_another_directory;
fn main() {
// do some stuff with these packages and die
}
I would need to depend on the serde_json and my some_private_packege_i_own_locally_in_another_directory.
(A bit similar to rust playground I suppose for a single time use)
Something similar to this from the command line would be great:
rustc /path/to/main.rs --dependency serde_json, my_package ...
You can specify a dependency with with extern flag, and you can specify the location of transitive dependencies, with -L dependency. You will have to compile each dependency, and all of it's dependencies manually:
// compile all of serde's dependencies
// compile all of hyper's dependencies
// compile serde
// compile hyper
rustc script.rs --crate-type bin -L dependency=~/tmp/deps --extern serde_json=~/tmp/deps/serde_json.rlib --extern hyper=~/tmp/deps/hyper.rlib
As you can tell, this would get very difficult, even with two direct dependencies. Instead, you can use cargo-script, which handles all of this for you:
cargo install cargo-script
cargo script -D hyper -D serde_json script.rs
I am trying to create an embed-friendly executable (small footprint and without dependency on the Rust standard library) that uses a library (wasmi) that already has support for a no_std build. New to Rust, I am simply piecing together instructions, but the gist of it appears to be follow the steps.
For the executable:
#![no_std]
#![no_main]
use core::panic::PanicInfo;
/// This function is called on panic.
#[panic_handler]
fn panic(_info: &PanicInfo) -> ! {
loop {}
}
#[no_mangle]
pub extern "C" fn _start(_argc: isize, _argv: *const *const u8) -> ! {
interpret(_argc, _argv);
loop {}
}
That is to:
include #![no_std]
define our entry (not main since we don't have a runtime that will call it)
and define a panic handler since the Rust std lib is not included to define it for us.
My Cargo file to compile this looks like this:
[package]
name = "driver"
version = "0.1.0"
edition = "2018"
[dependencies.wasmi]
path = "../../github_dev/wasmi"
features = ["core"]
default-features = false
test=false
bench=false
[profile.release]
panic = "abort"
lto = true
incremental=false
debug=true
opt-level = "z"
test=false
bench=false
and produces a very small binary that excludes any standard library symbols (using nm to check) and runs as expected.
The problem occurs when I actually try to call a function from the wasmi library. It is built with no_std via the features=core line. Doing an nm on the files in release/deps/libwasmi-*.rlib shows no standard library symbols. However when linking occurs with this command:
rustc --release --verbose -- -C link-arg=-nostartfiles
it leads to:
Compiling driver v0.1.0 (/home/my_home/wasmi_embed/driver)
Running rustc --edition=2018 --crate-name driver src/main.rs --color always --crate-type bin --emit=dep-info,link -C opt-level=3 -C panic=abort -C lto -C link-arg=-nostartfiles -C metadata=957eda2e590447ba -C extra-filename=-957eda2e590447ba --out-dir /home/my_home/wasmi_embed/driver/target/release/deps -L dependency=/home/my_home/wasmi_embed/driver/target/release/deps --extern libc=/home/my_home/wasmi_embed/driver/target/release/deps/liblibc-f7fb773c7b059a14.rlib --extern wasmi=/home/my_home/wasmi_embed/driver/target/release/deps/libwasmi-534aef1926b4eb6c.rlib
and an error occurs:
error[E0152]: duplicate lang item found: panic_impl.
--> src/main.rs:31:1
|
31 | / pub extern fn panic(_info: &PanicInfo) -> ! {
32 | | loop {}
33 | | }
| |_^
|
= note: first defined in crate `std`.
It seems Rust is trying to link in standard library support for at least panic handling, but I don't know why.
I would like help to understand why and to understand how to prevent it.
If I remove the panic_impl attribute then my executable compiles, but it includes a lot of standard library symbols that I am trying to prevent.
The example symbols I see are:
my_home#my_puter:~/wasmi_embed/driver/target/release$ nm --demangle -A -a -B -s --line-number test_2018 2>/dev/null | grep std
driver:00000000000264c0 t rust_begin_unwind /rustc/8e2063d02062ee9f088274690a97826333847e17//src/libstd/panicking.rs:311
driver:00000000000264a0 t rust_oom /rustc/8e2063d02062ee9f088274690a97826333847e17//src/libstd/alloc.rs:203
driver:000000000001f490 t rust_panic /rustc/8e2063d02062ee9f088274690a97826333847e17//src/libstd/panicking.rs:524
driver:0000000000025aa0 t _$LT$std..panicking..continue_panic_fmt..PanicPayload$LT$$u27$a$GT$$u20$as$u20$core..panic..BoxMeUp$GT$::get::he4f810e299a2e0b4 /rustc/8e2063d02062ee9f088274690a97826333847e17//src/libstd/panicking.rs:372
driver:00000000000259a0 t _$LT$std..panicking..continue_panic_fmt..PanicPayload$LT$$u27$a$GT$$u20$as$u20$core..panic..BoxMeUp$GT$::box_me_up::hd8430725259668a8 /rustc/8e2063d02062ee9f088274690a97826333847e17//src/libstd/panicking.rs:367
driver:0000000000021520 t _$LT$std..sys_common..process..DefaultEnvKey$u20$as$u20$core..borrow..Borrow$LT$std..ffi..os_str..OsStr$GT$$GT$::borrow::hbacd0cd7d7fbf1c1/rustc/8e2063d02062ee9f088274690a97826333847e17//src/libstd/sys_common/process.rs:27
driver:0000000000021570 t _$LT$std..error..$LT$impl$u20$core..convert..From$LT$alloc..string..String$GT$$u20$for$u20$alloc..boxed..Box$LT$$LP$dyn$u20$std..error..Err
... plus more
The above symbols are not found in any of the rlib files under the dep directory including libwasmi, nor are they found in the driver executable when not calling libwasmi code.
I've read a similar issue (hence my test=false and bench=false in the Cargo.toml) but that did not help. I've tried to build with just rustc with varying commands (excluding Cargo) but the error is the same. I've tried to compile wasmi as a static library (ar) and link it in, but being new to Rust I was spending a lot of time trying to link it in and it just wasn't happening.
I resolved this after seeking some help in the rust forums. enter link description here. Specifically, was not able to determine what was responsible for rust std lib being linked into my executable ... was it an issue with a crate or an issue with cargo or an issue with rustc or an issue with the linker. I did not know where the problem was born, but based on similar bugs filed I figured that somehow a crate was being compiled to bring in std lib unexpected. Turns out bug enter link description here was not related even though the error message was the same. I did not have an issue with unexpected propagations form different type of dependencies (dev-dependencies and build-dependencies). I tried all these techniques to pinpoint what was bringing in std lib:
I tried using cargo tree to list dependencies to list all the crate
dependencies:
wasmi v0.4.3 (/home/jlb6740/github_dev/wasmi)
├── byteorder v1.3.1 (/home/jlb6740/github_dev/byteorder)
├── hashbrown v0.1.8 (/home/jlb6740/github_dev/hashbrown)
│ ├── byteorder v1.3.1 (/home/jlb6740/github_dev/byteorder) ()
│ └── scopeguard v0.3.3 (/home/jlb6740/github_dev/scopeguard)
├── libm v0.1.2
├── memory_units v0.3.0
└── parity-wasm v0.31.0 (/home/jlb6740/github_dev/parity-wasm)
└── byteorder v1.3.1 (/home/jlb6740/github_dev/byteorder) ()
I tried using cargo rustc --verbose … but at this time verbose does
not indicate anything was using default features which may include
using std
I tried using cargo metadata … this generated a long list of
dependencies that was hard to parse, but I did see some instances
where scopeguard and byteorder had default features requiring std
support. I downloaded all of these crates and just hardcoded
attributes so that the crates would only build with no_std support.
I tried looking at the deps/ output and did an nm on all of the
rlibs to see if any of the libraries used symbols found in std. I
could not find that that was the case. I thought rlibs were like
static libraries and that anything they used would be included in
the rlib but apparently not.
I looked at cargo rustc -- -C --print-link-args to check out linker
flags but I could not find anything obvious telling me it was
bringing in std lib.
None of these things helped me to pinpoint what was introducing std lib. Ultimately the suggestion at the rust forums was to use cargo check for a target that does not allow std lib at all. Those with a * listed here: enter link description here have only core support. I tried that, running with --target=thumbv7m-none-eabi and saw:
error[E0463]: can’t find crate for alloc
–> /home/jlb6740/github_dev/hashbrown/src/lib.rs:44:1
|
44 | extern crate std as alloc;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^ can’t find crate
Turns out it was hashbrown which was a dependency of a dependency of my executable. It built no_std by default but had an extern std linked under a different name and which was guarded by a feature called “nightly”. The guard was disabled in my efforts to not build anything but no_std. Nothing I’d tried alerted me to the crate which was responsible until this. Seems there should be a better way to get a more comprehensive list of crate dependencies than what cargo tree provided, but changing the wasmi cargo to make sure the nightly feature was set solved my issue.
If I build a Rust application using Cargo with some crate dependencies, will any code in those dependencies that is unused by my application be eliminated from the final executable?
It looks like it. I made a test lib and bin crate side by side:
// hellobin/src/main.rs
extern crate hellolib;
fn main() {
hellolib::func1();
}
For the lib:
// hellolib/src/main.rs
pub fn func1() {
println!("Hello, world!");
}
pub fn func2() {
println!("Hello, other world!");
}
Building my binary and then inspecting symbols with nm:
$ nm target/debug/helloworld | grep hello
0000000100001360 t __ZN10helloworld4main17h749f61fb726f0a10E
00000001000014b0 T __ZN8hellolib5func117hec0b5301559d46f6E
Only the used function has a symbol in the final binary.
You can compile with cargo rustc -- -C link-dead-code though and you will see both symbols are present, including the unused one:
$ nm target/debug/helloworld | grep hello
0000000100001270 t __ZN10helloworld4main17h3104b73b00fdd798E
00000001000013d0 T __ZN8hellolib5func117hec0b5301559d46f6E
0000000100001420 T __ZN8hellolib5func217hc9d0886874057b84E
I believe (but I'm not sure) that it's the linker removing the dead code, so it may have still been compiled and then removed during linking.
TL;DR: Yes, every unused function is going to be excluded.
This is actually the job of LLVM that will at least keep track of every unused function. Any unused code (as in codepaths in function not taken across the entire Application) may require LTO (Link Time Optimizations) to be activated to turn your crate into one compilation unit and give LLVM a fighting chance.
I've got a Rust library with the following usual structure:
Cargo.toml
src
|--lib.rs
.cargo
|--config (specifies target=asmjs-unknown-emscripten)
target
|......
When I do cargo build, I get a new directory under target called asmjs-unknown-emscripten, but the .js files that I'd expect are not there.
As this user notes, you've got to do something special to export functions to asm.js besides marking them public:
Basically you have this boilerplate right now:
#[link_args = "-s EXPORTED_FUNCTIONS=['_hello_world']"]
extern {}
fn main() {}
#[no_mangle]
pub extern fn hello_world(n: c_int) -> c_int {
n + 1
}
Then you can use this in your javascript to access and call the function:
var hello_world = cwrap('hello_world', 'number', ['number']);
console.log(hello_world(41));
However, Rust complains about the #[link_args...] directive as deprecated. Is there any documentation out there that can explain how this works?
Very interesting question! I was running into similar dependency issues with fable.
I have checked Compiling Rust to your Browser - Call from JavaScript, Advanced Linking - Link args and How to pass cargo linker args however was not able to use cargo in the same way as rustc --target asmjs-unknown-emscripten call-into-lib.rs.
The closer I was able to get was to run both cargo and rustc like
cd lib1
cargo build --target asmjs-unknown-emscripten
rustc --target=asmjs-unknown-emscripten src\lib.rs
cd ..
cd lib2
cargo build --target asmjs-unknown-emscripten
rustc --target=asmjs-unknown-emscripten src\lib.rs --extern lib1=..\lib1\target\asmjs-unknown-emscripten\debug\liblib1.rlib
cd ..
cd lib3
cargo build --target asmjs-unknown-emscripten
rem rustc --target=asmjs-unknown-emscripten src\lib.rs --extern webplatform=..\lib3\target\asmjs-unknown-emscripten\debug\deps\libwebplatform-80d107ece17b262d.rlib
rem the line above fails with "error[E0460]: found possibly newer version of crate `libc` which `webplatform` depends on"
cd ..
cd app
cargo build --target asmjs-unknown-emscripten
cd ..
see the so-41492672-rust-js-structure. It allows to have several libraries that compile together to the JavaScript in the final application.
I still think some manual linking would help. Would be interested to know.
P.S. to see what rustc uses to link, you can pass -Z print-link-args to it.