Hi, What config are you trying to build? Did you try to run a clean build?
I built a couple of the protected mode STM32 boards, they all build with no error. On Wed, Mar 18, 2020 at 8:35 PM John Rippetoe <jrippe...@roboticresearch.com> wrote: > > Hello, > > I updated master on my repo yesterday and noticed that I can no longer > build STM32H7 or F7 based boards. The compiler error in question is > shown below. For what its worth, I am using standard arm-none-eabi > toolchain on Ubuntu Linux. > > LD: nuttx > nuttx/staging/libarch.a(stm32_allocateheap.o): In function > `mpu_configure_region': > nuttx/arch/arm/src/armv7-m/mpu.h:281: undefined reference to > `mpu_allocregion' > nuttx/arch/arm/src/armv7-m/mpu.h:296: undefined reference to > `mpu_log2regionceil' > nuttx/arch/arm/src/armv7-m/mpu.h:298: undefined reference to > `mpu_log2regionceil' > nuttx/arch/arm/src/armv7-m/mpu.h:315: undefined reference to `mpu_subregion' > > These are all functions that are declared in arch/arm/src/armv7-m/mpu.h > and defined in arch/arm/src/armv7-m/up_mpu.c . They are called within > various inlined functions defined in mpu.h. The issue stems from a > change made by commit 3972510 > <https://github.com/apache/incubator-nuttx/commit/39725109fac627ba70300c858d3c6e13187824f6>, > where the logic for checking that inline functions are allowed was > changed to ensure the code is being compiled with at least the C99 > standard. > > I am still learning how the build system for NuttX is organized, so I > don't know exactly where to specify which C standard to use. Should this > be specified by the host system or be included as a flag in the build > files for affected chips? If it is the latter, I see two possible places > it could be added > > 1. In the chip Make.defs > 2. In each board Make.defs, where the ARCHCFLAGS variable is already > specified > > Since this affects all boards with a particular chip, it seems better to > add it to the chip Make.defs. However, given that all the compiler flags > are currently specified at the board level, it seems better to put it > there for consistency's sake. > > I'm not sure how many other chips are affected by this issue yet, but it > is presumably anything using inline functions. > > Thanks, > > John Rippetoe > > > CONFIDENTIALITY NOTICE: This communication may contain private, confidential > and privileged material for the sole use of the intended recipient. If you > are not the intended recipient, please delete this e-mail and any attachments > permanently. >
