Building on windows w/ GCC10 version of ARM Toolchain (latest) #194
Replies: 4 comments 2 replies
-
It's cool to see that you are building the code 👍 This may indeed be worth resolving at some point.
If you update to the latest build, you'll find some things in InventorHub.imu already. We're in the process of making it non-experimental. I'm curious, did you build from source to tweak some of the IMU device settings? If so, which ones? We're contemplating which settings should be user-accessible from the Python script. So if you need anything in particular, now is a good time to ask :) Also check out this branch of the docs, which has some of it documented as well. |
Beta Was this translation helpful? Give feedback.
-
We will also gladly take pull requests to fix the errors. Although I would rather fix the problem rather than ignore the errors. |
Beta Was this translation helpful? Give feedback.
-
Fixed in pybricks/pybricks-micropython@14654bb and pybricks/pybricks-micropython@220afa2 |
Beta Was this translation helpful? Give feedback.
-
I also tried GCC 10 on our other hubs, but they wouldn't boot using firmware compiled with GCC 10. So apparently something is broken in GCC 10. |
Beta Was this translation helpful? Give feedback.
-
H pybricks team!,
Firstly: thanks for all the efforts on pybricks! It is truly great!
TL;DR - If you need to build with GCC10 it seems you need to add Wno-error=zero-length-bounds and -fcommon in the stm32.mk file.
This is a very non urgent observation on toolchain behavior when following the instructions to build pybricks-micropython. I was setting up a development environment to putter around with the IMU in experimental. Since I couldn't get the BLE communication working with InventorHub on OSX (different issue), I switched to Windows and setup a dev environment following the instructions on the Contributions page. I tried building with the latest Arm Toolchain build however it failed with a -Werror=zero-length-bounds due to the variable length struct in the lpf2 module. I worked past that by adding a -Wno-error=zero-length-bounds in the stm32.mk file. Now it only prints the warning :
It then failed on the linker with almost every .o file having many duplicate definitions due to common.h (some sample messages below):
It appears GCC10 makes -fno-common to be the default instead of -fcommon so after adding that to the CFLAGS as well,
voila it worked!
Just figured I'd post this out in case anyone else also tried with GCC10 and ran into the same issues. Apologies if this is obvious.
Beta Was this translation helpful? Give feedback.
All reactions