Closed julianoes closed 3 years ago
The only reason is the inherent risk of regressions / latent defects.
CI failed
It looks mostly like warnings, so I would remove -Werror
or otherwise I think it would require @davids5's help to figure the issues out.
I am not sure what was being experienced. Was somthing merged in our code that broke this? Also
On the read me:
Use ONLY arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 7-2017-q4-major) 7.2.1 20170904 (release) [ARM/embedded-7-branch revision 255204]
Version 9.3 will cause issues with flash programing and not work at this time!
~~~
I get a 100% clean build with master.
git submodule status
3ddab192f4ca6a3a5c4cdd12f7d15ea076eb98e3 lib/kinetis/NXP_Kinetis_Bootloader_2_0_0 (heads/px4_bootloader_NXP_Kinetis_Bootloader_2_0_0)
0d5e51a8a7b24c8bc93ca849eb670bc55b02e091 libopencm3 (v0.8.0~468)
b29f40b567a983b36742f562fa58302326065580 monocypher (3.1.1-27-gb29f40b)
@davids5 you're right, with Ubuntu 20.04 it's all clean.
With Arch Linux I get:
BUILD lib/stm32/f0
/bin/sh: -c: line 2: unexpected EOF while looking for matching `"'
/bin/sh: -c: line 3: syntax error: unexpected end of file
make[1]: *** [Makefile:69: lib/stm32/f0] Error 2
make[1]: Leaving directory '/home/julianoes/src/Bootloader/libopencm3'
make: *** [Makefile:212: libopencm3] Error 2
And that goes away with master, however, I'm happy to ignore that.
BTW I just happend to get the same error (on Fedora) so at some point we do need a fix.
Can we fork and backport a make file to solve this? The issues is the testing all the builds on real HW.
@bkueng - Thank you that looks safe enough.
@LorenzMeier do you want to dedicate resource to testing with latest master or forking and back porting?
@bkueng thanks. I've cherry-picked these two commits in https://github.com/PX4/libopencm3/tree/cherry-picked-fixes and switched to this branch in #198.
This fixes the build for me. Is there a reason not to update it?