Building for STM32F4 target fails on lvgl-sys #50

Closed
opened 2021-06-02 04:21:57 +00:00 by fralalonde · 4 comments
fralalonde commented 2021-06-02 04:21:57 +00:00 (Migrated from github.com)

This might be a very basic issue as I am not too familiar with C toolchain cross-compilation. The Rust side of thing should be ok as I have a working project deploying to STM32F4 (blackpill).

I'm on Linux (Arch), with the latest arm-none-eabi-gcc and arm-none-eabi-newlib installed. I've created a sample Cargo project as a subfolder of lvgl-rs, where I've set the thumbv7m-none-eabi target.

My cargo command-line is DEP_LV_CONFIG_PATH=pwd cargo build -Zfeatures=build_dep, the -Z part of which I picked from a closed issue similar to what I was experiencing.

The error message is

  running: "arm-none-eabi-ar" "cq" "/home/fralalonde/Code/lvgl-rs/target/thumbv7m-none-eabi/debug/build/lvgl-

[...]

sys-09c2f1d2cfdf5925/out/lvgl_sys.o"
  exit status: 0
  running: "arm-none-eabi-ar" "s" "/home/fralalonde/Code/lvgl-rs/target/thumbv7m-none-eabi/debug/build/lvgl-sys-09c2f1d2cfdf5925/out/liblvgl.a"
  exit status: 0
  cargo:rustc-link-lib=static=lvgl
  cargo:rustc-link-search=native=/home/fralalonde/Code/lvgl-rs/target/thumbv7m-none-eabi/debug/build/lvgl-sys-09c2f1d2cfdf5925/out

  --- stderr
  /home/fralalonde/Code/lvgl-rs/lvgl-sys/vendor/lvgl/src/lv_misc/lv_area.h:17:10: fatal error: 'string.h' file not found
  /home/fralalonde/Code/lvgl-rs/lvgl-sys/vendor/lvgl/src/lv_misc/lv_area.h:17:10: fatal error: 'string.h' file not found, err: true
  thread 'main' panicked at 'Unable to generate bindings: ()', lvgl-sys/build.rs:124:10

It's a fact that there is no string.h file in my /usr/lib/gcc/arm-none-eabi/11.1.0/include dir, and I have no idea where I should get it from or how I could provide it to the lvgl-sys build process.

As a general observation, it would be nice to have some examples targeting embeded targets (code & build) - unless I couldn't find them? If I fix my sample, I'd be happy to make into a PR for others to follow.

This might be a very basic issue as I am not too familiar with C toolchain cross-compilation. The Rust side of thing should be ok as I have a working project deploying to STM32F4 (blackpill). I'm on Linux (Arch), with the latest `arm-none-eabi-gcc` and `arm-none-eabi-newlib` installed. I've created a sample Cargo project as a subfolder of lvgl-rs, where I've set the `thumbv7m-none-eabi` target. My cargo command-line is `DEP_LV_CONFIG_PATH=`pwd` cargo build -Zfeatures=build_dep`, the -Z part of which I picked from a closed issue similar to what I was experiencing. The error message is ``` running: "arm-none-eabi-ar" "cq" "/home/fralalonde/Code/lvgl-rs/target/thumbv7m-none-eabi/debug/build/lvgl- [...] sys-09c2f1d2cfdf5925/out/lvgl_sys.o" exit status: 0 running: "arm-none-eabi-ar" "s" "/home/fralalonde/Code/lvgl-rs/target/thumbv7m-none-eabi/debug/build/lvgl-sys-09c2f1d2cfdf5925/out/liblvgl.a" exit status: 0 cargo:rustc-link-lib=static=lvgl cargo:rustc-link-search=native=/home/fralalonde/Code/lvgl-rs/target/thumbv7m-none-eabi/debug/build/lvgl-sys-09c2f1d2cfdf5925/out --- stderr /home/fralalonde/Code/lvgl-rs/lvgl-sys/vendor/lvgl/src/lv_misc/lv_area.h:17:10: fatal error: 'string.h' file not found /home/fralalonde/Code/lvgl-rs/lvgl-sys/vendor/lvgl/src/lv_misc/lv_area.h:17:10: fatal error: 'string.h' file not found, err: true thread 'main' panicked at 'Unable to generate bindings: ()', lvgl-sys/build.rs:124:10 ``` It's a fact that there is no `string.h` file in my `/usr/lib/gcc/arm-none-eabi/11.1.0/include` dir, and I have no idea where I should get it from or how I could provide it to the lvgl-sys build process. As a general observation, it would be nice to have some examples targeting embeded targets (code & build) - unless I couldn't find them? If I fix my sample, I'd be happy to make into a PR for others to follow.
rafaelcaricio commented 2021-06-02 13:50:35 +00:00 (Migrated from github.com)

Hi @fralalonde ,

I do have one old example here: https://github.com/rafaelcaricio/pinetime-rs (it is using the branch of the PR https://github.com/rafaelcaricio/lvgl-rs/pull/27) I was testing the input device API in an actual device at the time.

The error you are getting seems familiar. What I can say is that I do embed a Rust version of the string.h ABI implementation in the lvgl-sys crate. So you can really copy a string.h header file from somewhere and drop it in the same dir you have pointed the DEP_LV_CONFIG_PATH env variable and at linking time it should match with the string_impl.rs.

Please try that and let me know if that works for you.

Hi @fralalonde , I do have one old example here: https://github.com/rafaelcaricio/pinetime-rs (it is using the branch of the PR https://github.com/rafaelcaricio/lvgl-rs/pull/27) I was testing the input device API in [an actual device](https://www.pine64.org/pinetime/) at the time. The error you are getting seems familiar. What I can say is that I do embed [a Rust version of the `string.h` ABI implementation](https://github.com/rafaelcaricio/lvgl-rs/blob/master/lvgl-sys/src/string_impl.rs) in the `lvgl-sys` crate. So you can really copy a `string.h` header file from somewhere and drop it in the same dir you have pointed the `DEP_LV_CONFIG_PATH` env variable and at linking time it should match with the `string_impl.rs`. Please try that and let me know if that works for you.
rafaelcaricio commented 2021-06-02 13:56:15 +00:00 (Migrated from github.com)

Also FYI, I'm actively working on an upgrade of the LVGL-rs bindings API. I realized that the existence of the UI struct is cumbersome and makes the usage of the library less flexible, so I'm removing it. So I believe it will simplify and make the usage of LVGL in Rust projects more expressive. Since you seem to be actively trying the library, I think you would be glad to know. :)

Also FYI, I'm actively working on an upgrade of the LVGL-rs bindings API. I realized that the existence of the `UI` struct is cumbersome and makes the usage of the library less flexible, so I'm removing it. So I believe it will [simplify](https://github.com/rafaelcaricio/lvgl-rs/blob/65286d950a29445daa0cb7968efc7278eea0bda6/examples/demo.rs#L32) and make the usage of LVGL in Rust projects [more expressive](https://github.com/rafaelcaricio/lvgl-rs/blob/65286d950a29445daa0cb7968efc7278eea0bda6/examples/demo.rs#L58). Since you seem to be actively trying the library, I think you would be glad to know. :)
fralalonde commented 2021-06-02 14:29:10 +00:00 (Migrated from github.com)

Fixed it by adding /usr/arm-none-eabi/include to the C_INCLUDE_PATH:

C_INCLUDE_PATH=/usr/arm-none-eabi/include/ DEP_LV_CONFIG_PATH=`pwd`/include cargo build -Zfeatures=build_dep

Maybe it's an Arch thing [sigh] or some quirk of my station. I didn't get anything to display yet but the build completes successfully which is always a good sign with cargo.

Thanks for the heads up on the upcoming upgrade!

Fixed it by adding `/usr/arm-none-eabi/include` to the `C_INCLUDE_PATH`: ``` C_INCLUDE_PATH=/usr/arm-none-eabi/include/ DEP_LV_CONFIG_PATH=`pwd`/include cargo build -Zfeatures=build_dep ``` Maybe it's an Arch thing [sigh] or some quirk of my station. I didn't get anything to display yet but the build completes successfully which is always a good sign with cargo. Thanks for the heads up on the upcoming upgrade!
obedm503 commented 2021-10-11 00:11:45 +00:00 (Migrated from github.com)

This fixed it for me as well except the correct include path is /usr/lib/arm-none-eabi/include/ (notice the /lib). Would be good to have this in the readme along with the requirement to install gcc-arm-none-eabi on linux.

This fixed it for me as well except the correct include path is `/usr/lib/arm-none-eabi/include/` (notice the `/lib`). Would be good to have this in the readme along with the requirement to install `gcc-arm-none-eabi` on linux.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: rafaelcaricio/lvgl-rs#50
No description provided.