CrossCompile

[MasterPlexus]

Hi There,
I see in the assets several versions are avalible, what is not that bad. but currently I miss a mipsel version . The reason is, because I have a Receiver (VU+Duo2) which is running anyhow permanently. To set up there Neolink would be a good fit in my eyes.
Could someone guide me, on how to cross compile to mipsel32 ? And if there could be dependencys which may could have problems?

[QuantumEntangledAndy]

Have a look at the build script in .github/workflows/ what we do is:

• spin up a Debian docker
• pull the packages in the desired arch
• setup the compilers
• setup the cargo
• build the target arch

[MasterPlexus]

Thanks for it. As it looks like YML is not possible to let run local, I need to extract the steps local, and then try it. If I come to the conclusion then I'll try to add a Mipsl arch if this would be ok for you at a pull request.

[MasterPlexus]

So I started to have a look. I'm faling down, as Debian has decommissioned Mipsel support, and only have in current releases Mips64 support... So this would mean I have to install localy a docker with debian boockworm. I never worked with Dockers, and Virtual machines are not that convenient to me.

What I has seen, it looks like, in bookworm (what you use to build the assets), contains all what is needed for mipsel. My Question would be, if you could try a release, including

- arch: mipsel
   target: mips-unknown-linux-gnu
   gcc: mips-linux-gnu
   pkgconfig: mips-linux-gnu  

I think it should work in my eyes for the package dependancys..

If not possible for you, or you may fell its not worth, then I will retry later when I have more time to build a new bookworm instance to try...

Thanks
MP

[QuantumEntangledAndy]

Can you PR that change yourself please?

Also just to make sure, can you get the mipsel gstreamer and OpenSSL dependencies on your target device? If not you'll need a way to get them on the target device along with neolink.

[MasterPlexus]

The Firmware I use is openPLI, this contains gStreamer and openSSL as basis. I assume the other Boxes do it the same, but the problem may is, that the versions could differ. May at the beginning it shuld be tested more deeply then.

Will make a pr. Thanks.

[MasterPlexus]

Hi So. After seeing that mipsel is stopped in current version of rust, I also stopped my PR for it. It will fail for sure.
I started now localy downgrade Rust to 1.71.1, and some things will be build with it. Unfortunatly there is one message, not sure why:

   Compiling ring v0.16.20
     Running `/home/dirk/neolink/target/release/build/ring-5570a5263bc4be86/build-script-build`
     Running `/home/dirk/.rustup/toolchains/1.71.1-x86_64-unknown-linux-gnu/bin/rustc --crate-name thiserror_impl --edition=2021 /home/dirk/.cargo/registry/src/index.crates.io-6f17d22bba15001f/thiserror-impl-1.0.50/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --diagnostic-width=102 --crate-type proc-macro --emit=dep-info,link -C prefer-dynamic -C embed-bitcode=no -C debug-assertions=off -C metadata=e83a8f79d8c8e405 -C extra-filename=-e83a8f79d8c8e405 --out-dir /home/dirk/neolink/target/release/deps -L dependency=/home/dirk/neolink/target/release/deps --extern proc_macro2=/home/dirk/neolink/target/release/deps/libproc_macro2-64beee700334bea8.rlib --extern quote=/home/dirk/neolink/target/release/deps/libquote-2cf43f582451bc36.rlib --extern syn=/home/dirk/neolink/target/release/deps/libsyn-ca157895c2a0433c.rlib --extern proc_macro --cap-lints allow`
error: failed to run custom build command for `ring v0.16.20`

Caused by:
  process didn't exit successfully: `/home/dirk/neolink/target/release/build/ring-5570a5263bc4be86/build-script-build` (exit status: 101)
  --- stderr
  thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /home/dirk/.cargo/registry/src/index.crates.io-6f17d22bba15001f/ring-0.16.20/build.rs:358:10
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

You have an Idea on it? I'm too far away from rust :-/

[MasterPlexus]

Ok, it becomes harder. as far as I could see, the Ring depends on rustsl, and booth where marked as non Mips... So I fear the changes becomes lower and lower...

[QuantumEntangledAndy]

Looks like the rabbit hole goes quite deep. Not sure we can remove the ring dependency. I think it is used by a few packages we use.