Rust Linking Issues for Windows and Headless

[WittsEnd2]

Binary Ninja Version - Latest Dev API

Bug Description
For the Rust API, whenever I try to create a Headless build (or any build on Windows), there are linking issues. Specifically, it cannot link to any function from the C API This is whenever I tell Cargo that a dependency is Binary Ninja via Git or Locally.

A Linux plugin doesn't have these linking issues.

To Reproduce
Steps to reproduce the behavior:

1. Give Binary Ninja as a dependency in Cargo.
2. Use one of the examples from the Binary Ninja repository for testing.
3. cargo build

Expected behavior
Compile a binary (for headless and windows plugin)

Version and Platform (required):

• Binary Ninja: Dev 2.4.2487 (if tested in stable, please also test the development channel via the "update channel" option)
• OS: Ubuntu Linux and Windows
• Version Ubuntu 20.04, Windows 10 2021 H2 Update

[ElykDeer]

If Lots of linking issues. is your expected behaviour, it sounds like this is closed. /s

What version/chanel of cargo are you using?

[jrozner]

I'm experiencing this as well on both macos and windows. Using rust nightly through cargo (up to date as of yesterday). Using up to date dev binary ninja and up to date dev branch of binaryninja-api for the rust crate.

From MacOS:

  = note: Undefined symbols for architecture x86_64:
            "_BNLog", referenced from:
                _$LT$binaryninja..logger..Logger$u20$as$u20$log..Log$GT$::log::h5a4b9fd3a51e9fc9 in libbinaryninja-a65608b7960cffa3.rlib(binaryninja-a65608b7960cffa3.binaryninja.bp0gjo5v-cgu.8.rcgu.o)
            "_BNGetArchitectureRegisterByName", referenced from:
                binaryninja::architecture::ArchitectureExt::register_by_name::h9ec0127f6368569b in binja_msp430.55qt0ochjpo97pvj.rcgu.o
            "_BNLowLevelILAddExpr", referenced from:
                binaryninja::llil::lifting::_$LT$impl$u20$binaryninja..llil..function..Function$LT$A$C$binaryninja..llil..function..Mutable$C$binaryninja..llil..function..NonSSA$LT$binaryninja..llil..function..LiftedNonSSA$GT$$GT$$GT$::unimplemented::h5600b04d45742cb9 in binja_msp430.hurpbjyt8zhf2fp.rcgu.o
            "_BNRegisterCallingConvention", referenced from:
                binaryninja::callingconvention::register_calling_convention::h7ccf7e27bca7bbd8 in binja_msp430.4mqerrnnx5brpmpi.rcgu.o
            "_BNCreateCallingConvention", referenced from:
                binaryninja::callingconvention::register_calling_convention::h7ccf7e27bca7bbd8 in binja_msp430.4mqerrnnx5brpmpi.rcgu.o
            "_BNFreeCallingConvention", referenced from:
                _$LT$binaryninja..callingconvention..CallingConvention$LT$A$GT$$u20$as$u20$binaryninja..rc..RefCountable$GT$::dec_ref::h7336a17657246c74 in binja_msp430.4mqerrnnx5brpmpi.rcgu.o
            "_BNGetBinaryViewTypeByName", referenced from:
                binaryninja::custombinaryview::BinaryViewType::by_name::h6b4980edabc9d07b in binja_msp430.151nk7dd48llq6kb.rcgu.o
            "_BNGetDefaultArchitectureFlagConditionLowLevelIL", referenced from:
                binaryninja::llil::lifting::get_default_flag_cond_llil::h7aa90002a13aff95 in binja_msp430.3vdy2bmtlmtbpcyq.rcgu.o
            "_BNAllocString", referenced from:
                binaryninja::string::BnString::new::h34e5809552eeef4d in libbinaryninja-a65608b7960cffa3.rlib(binaryninja-a65608b7960cffa3.binaryninja.bp0gjo5v-cgu.5.rcgu.o)
            "_BNSetArchitectureDefaultCallingConvention", referenced from:
                binaryninja::architecture::ArchitectureExt::set_default_calling_convention::hb4738d1046a10424 in binja_msp430.55qt0ochjpo97pvj.rcgu.o
            "_BNGetDefaultArchitectureFlagWriteLowLevelIL", referenced from:
                binaryninja::architecture::register_architecture::cb_flag_write_llil::hb07a038963bfc1ce in binja_msp430.2dxluzd90bnpu7va.rcgu.o
                binaryninja::llil::lifting::get_default_flag_write_llil::h4c5bdafe1531033f in binja_msp430.3vdy2bmtlmtbpcyq.rcgu.o
            "_BNRegisterArchitecture", referenced from:
                binaryninja::architecture::register_architecture::h9c2fad781ab9fb8b in binja_msp430.2dxluzd90bnpu7va.rcgu.o
            "_BNRegisterArchitectureForViewType", referenced from:
                binaryninja::custombinaryview::BinaryViewTypeExt::register_arch::hab26304b8266af6b in binja_msp430.151nk7dd48llq6kb.rcgu.o
            "_BNGetDefaultIncomingVariableForParameterVariable", referenced from:
                binaryninja::callingconvention::register_calling_convention::cb_incoming_var_for_param::_$u7b$$u7b$closure$u7d$$u7d$::h65a8d9c9763a684f in binja_msp430.4mqerrnnx5brpmpi.rcgu.o
            "_BNGetDefaultParameterVariableForIncomingVariable", referenced from:
                binaryninja::callingconvention::register_calling_convention::cb_incoming_param_for_var::_$u7b$$u7b$closure$u7d$$u7d$::h91a511974f845577 in binja_msp430.4mqerrnnx5brpmpi.rcgu.o
          ld: symbol(s) not found for architecture x86_64
          clang: error: linker command failed with exit code 1 (use -v to see invocation)

[WittsEnd2]

Whoops, my bad! The expected behavior is to compile haha.

I am using:

Cargo: 1.5.4 - Nightly 
Rustc: 1.5.5 - Nightly

[ElykDeer]

I'm still confirming this, but I think this is a regression in cargo.

Everything works on my Mac on 1.53.0-nightly, and everything was working on Linux for me before I updated nightly (not sure from what version). Seems like it's no longer propagating the linker arguments from binaryninjacore-sys.

[ElykDeer]

Sure enough, if I run rustup install nightly-2021-04-24 and then rustup run nightly-2021-04-24 cargo run on the basic_script example, everything works again.

I'll see if there's a provided workaround from Rust.

[ElykDeer]

Unfortunately it seems that we were relying on a bug, and that any ability for a crate to provide linking dependencies for crates that import it is an intended anti-pattern: see rust-lang/cargo#9554.

The only solution at the moment seems to make all dependants include their own build.rs until rpath has better first-class support. I'll push a rust/examples/template.