Giters

tracel-ai / burn

Burn is a new comprehensive dynamic Deep Learning Framework built using Rust with extreme flexibility, compute efficiency and portability as its primary goals.

Home Page:https://burn.dev

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Compiling error when target is 'arm-unknown-linux-gnueabihf' - Error: 'ARM_UNKNOWN_LINUX_GNUEABIHF_OPENSSL_LIB_DIR'

exo-cortex opened this issue · comments

commented

Hi, I tried to build a very small burn-example - the 'guide'-example that I wanted to deploy on a rasberry pi zero w (the first one).
I tried this with the most basic code before where I only added two tensors together (also from the burn-book) - this works fine when I crosscompile to raspberry pi zero. (using the 'arm-unknown-linux-gnueabihf'-target).
I tried removing stuff until it worked (in fact I even removed everything in main.rs except the 'println!( ... )'-statement. I only have this as a dependency in my Cargo.toml:

burn = { version = "0.13", features = ["train", "vision", "ndarray"], default-features = false }

It appears that removing "vision" fixes the problem. Is there a workaround to remove this ssl-dependency from "vision". Or another way around this?
I am trying to get a few small models to work on embedded devices. Training a model on my desktop and running the model in a constrained environment.

The error I get when compiling:

$ cargo build --release
   Compiling serde_derive v1.0.204
   Compiling tokio-macros v2.3.0
   Compiling openssl-macros v0.1.1
   Compiling openssl-sys v0.9.102
   Compiling thiserror-impl v1.0.61
   Compiling regex-automata v0.4.7
   Compiling derive-new v0.6.0
   Compiling ipnet v2.9.0
   Compiling number_prefix v0.4.0
   Compiling rustversion v1.0.17
   Compiling libsqlite3-sys v0.27.0
   Compiling url v2.5.2
   Compiling signal-hook v0.3.17
   Compiling paste v1.0.15
   Compiling crossbeam-channel v0.5.13
   Compiling crc32fast v1.4.2
   Compiling rustix v0.38.34
   Compiling bstr v1.9.1
   Compiling matrixmultiply v0.3.8
   Compiling weezl v0.1.8
error: failed to run custom build command for `openssl-sys v0.9.102`

Caused by:
  process didn't exit successfully: `/home/lroesel/Code/rust/learn_burn/rp0_inference/target/release/build/openssl-sys-eb30fa46bce2d8a1/build-script-main` (exit status: 101)
  --- stdout
  cargo:rerun-if-env-changed=ARM_UNKNOWN_LINUX_GNUEABIHF_OPENSSL_LIB_DIR
  ARM_UNKNOWN_LINUX_GNUEABIHF_OPENSSL_LIB_DIR unset
  cargo:rerun-if-env-changed=OPENSSL_LIB_DIR
  OPENSSL_LIB_DIR unset
  cargo:rerun-if-env-changed=ARM_UNKNOWN_LINUX_GNUEABIHF_OPENSSL_INCLUDE_DIR
  ARM_UNKNOWN_LINUX_GNUEABIHF_OPENSSL_INCLUDE_DIR unset
  cargo:rerun-if-env-changed=OPENSSL_INCLUDE_DIR
  OPENSSL_INCLUDE_DIR unset
  cargo:rerun-if-env-changed=ARM_UNKNOWN_LINUX_GNUEABIHF_OPENSSL_DIR
  ARM_UNKNOWN_LINUX_GNUEABIHF_OPENSSL_DIR unset
  cargo:rerun-if-env-changed=OPENSSL_DIR
  OPENSSL_DIR unset
  cargo:rerun-if-env-changed=OPENSSL_NO_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG_ALLOW_CROSS_arm-unknown-linux-gnueabihf
  cargo:rerun-if-env-changed=PKG_CONFIG_ALLOW_CROSS_arm_unknown_linux_gnueabihf
  cargo:rerun-if-env-changed=TARGET_PKG_CONFIG_ALLOW_CROSS
  cargo:rerun-if-env-changed=PKG_CONFIG_ALLOW_CROSS
  cargo:rerun-if-env-changed=PKG_CONFIG_arm-unknown-linux-gnueabihf
  cargo:rerun-if-env-changed=PKG_CONFIG_arm_unknown_linux_gnueabihf
  cargo:rerun-if-env-changed=TARGET_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_arm-unknown-linux-gnueabihf
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_arm_unknown_linux_gnueabihf
  cargo:rerun-if-env-changed=TARGET_PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR
  run pkg_config fail: pkg-config has not been configured to support cross-compilation.

  Install a sysroot for the target platform and configure it via
  PKG_CONFIG_SYSROOT_DIR and PKG_CONFIG_PATH, or install a
  cross-compiling wrapper for pkg-config and set it via
  PKG_CONFIG environment variable.

  --- stderr
  thread 'main' panicked at /home/lroesel/.cargo/registry/src/index.crates.io-6f17d22bba15001f/openssl-sys-0.9.102/build/find_normal.rs:190:5:


  Could not find directory of OpenSSL installation, and this `-sys` crate cannot
  proceed without this knowledge. If OpenSSL is installed and this crate had
  trouble finding it,  you can set the `OPENSSL_DIR` environment variable for the
  compilation process.

  Make sure you also have the development packages of openssl installed.
  For example, `libssl-dev` on Ubuntu or `openssl-devel` on Fedora.

  If you're in a situation where you think the directory *should* be found
  automatically, please open a bug at https://github.com/sfackler/rust-openssl
  and include information about your system as well as this message.

  $HOST = x86_64-unknown-linux-gnu
  $TARGET = arm-unknown-linux-gnueabihf
  openssl-sys = 0.9.102


  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...

I am using toolchain stable-x86_64-unknown-linux-gnu (default) on Arch linux in WSL at the moment.

What do I do now?

commented 
Make sure you also have the development packages of openssl installed.
For example, `libssl-dev` on Ubuntu or `openssl-devel` on Fedora.

Have you tried installing openssl?

The openssl dependency comes from other dependencies that we use. More than one crate seems to have that dependency so I think you'll have issues completely avoiding it.

commented

Hi,
I am using Arch Linux (inside WSL). There I have installed openssl

1 core/openssl 3.3.1-1 (4.9 MiB 11.0 MiB) (Installed)
    The Open Source toolkit for Secure Sockets Layer and Transport Layer Security

But, having thought about it a little and testing it again, I just found out, that I don't have this error if I don't use the arm-unknown-linux-gnueabihf-target (by removing the .cargo/ folder which contains the config.toml that declares the target.)

Another thing that just came to mind:
I have encountered a problem when I was trying to build an application that was depending on rustls for arm-unknown-linux-gnueabihf. rustls was depending on a crate called aws-lc-rs for the cryptography which does not support #![no_std] ( see here.)
As an alternative rustls can be used with the feature ring instead - which I did successfully.
So maybe this is a the same problem?
For an explanation regarding rustls see here.
I'm not sure if this is the issue, as I don't see rustls as a direct depencendy. But maybe it is somehow included in the vision-feature? (I guess it has to do with the downloading of the mnist-dataset from the servers.

I hope this helps a little.

commented

Ahh that's likely it. reqwest is used to download the mnist dataset from the web and it depends on hyper-rustls which in turn pulls on rustls.

commented

Hm, would it be for me to quickly modify this somehow? I am not too familiar yet with the possibilities of the Cargo.toml. In fact I would have to modify a sub-sub-sub-sub-dependencie's feature (enabling ring), wouldn't I?

I'm struggling to see the forest for the trees probably. But wouldn't the simplest way (in my case - cross-compilation of only the inference-part and so on) be to copy the code from mnist.rs, remove the download-code and use that instead?

commented

I think that's a good start. If that works than you know what the issue is.

commented

Thank you! I managed to cross-compile a programm that runs on my raspberry pi (zero - very slow of course), that loads a model (trained on my desktop) and performs inference of mnist test-images. Works great! :D

commented

That's awesome! I'll close this issue for now but feel free to reopen if needed.

I should get myself a raspberry pi and make a demo at some point. Would be a cool example for the full end-to-end process.