sysroot not found for LEDE/OpenWrt targets

[janbraiins]

First of all, thank you for the development for such an non-trivial tool. I have followed your documentation and have hit the following problem:

 ERROR cargo_dinghy > Error: no sysroot found in toolchain "/my/path/to/toolchain/lede-meta/build/zynq/lede/staging_dir/toolchain-arm_cortex-a9+neon_gcc-5.4.0_musl-1.1.16_eabi"

The toolchain generated by Lede/OpenWRT doesn't have the expected layout.

Why do you need the full sysroot in the first place? Cargo is able to cross compile the full executable as well as only the test configuration. It is just not able to deploy and run the cross compiled tests...:

cargo test --target=arm-unknown-linux-musleabi
Syntax error: word unexpected (expecting ")")
error: test failed, to rerun pass '--bin foo' 

Running the test failed obviously, however I can do the manual steps:

scp target/arm-unknown-linux-musleabi/debug/foo-2794d1068ffc6a94 user@mytarget.local:~/ 
ssh user@mytarget.local -C ./foo-2794d1068ffc6a94

The only thing for the cross compilation to work is local project's cargo config that specifies the required linker:

cat .cargo/config
[target.arm-unknown-linux-musleabi]
linker = "arm-openwrt-linux-muslgnueabi-gcc"

I believe cargo now has full information to build the project assuming my cross toolchain is accessible in the path - and this is trivial to achieve. Maybe I am not seeing any of the details, however in case of android toolchain I would assume this would be roughly the same, too.

Thank you for any input on this topic.

[kali]

Hi, thanks for interest !

It's right that we may not always need the sysroot... I guess the fact that our main targets were phones and pis made it natural to assume it would always be there, and always needed. Our primary use-case involves compling C -sys bindings and linking with system libraries so sysroot management is not something we can dispense with completely.

I'll have a look if I an easily add a "non-sysroot" target option...

I also hate to say that, but with cargo becoming smarter and smarter, dinghy value is getting smaller. In your use case, you could just use cargo and setup a simple sh script (which you can hand to cargo with a CARGO_..._RUNNER option) to scp and ssh/exec the test on your remote device.

As a matter of fact, we have started an effort to split dinghy in two and working around cargo instead of using cargo as library: dingy would just discover plugged-in or known devices, setup the environment, call the regular cargo executable with the right parameters. It would then act as a simpel runner, even for the incredibly convoluted ios case.

[janbraiins]

Thank you for the insight, we are just starting to get rust on board for our project. I will look into the runner option, too. I am guessing it's kind of similar to the situation with xargo as a separate tool vs xbuild as cargo extension when developing for bare metal.

[MarcTreySonos]

the sysroot is required only for the crates where TARGET_SYSROOT need to be defined , mostly when a configure script is involved : https://github.com/snipsco/dinghy/blob/061be68744cb64eb0437ad9e9491f201fa31d10d/dinghy-lib/src/toolchain.rs#L86

[mfronczyk]

@kali Is the work on simplifying Dinghy still in progress and is the project active? You also mentioned that Dinghy value is getting smaller. Is there a better way now to run cargo tests on mobile devices?

[kali]

@mfronczyk It's a bit in limbo. It could come back, but not short term. The current version is "good enough" for my company use, so it's unlikely we'll invest the weeks on the splitting.

We are still relying on the master version, though, so we are going to keep it alive for quite a while.

My mid-term strategy is actually to wait a bit... Cargo is evolving in the right direction, as Xargo and other integrated build tools pulls for more flexibility. It may make more of dinghy redundant, to the point where the only remaining relevant part is the ios integration.