Issue #230: `error: unknown type name 'constexpr'`

Development
1

error: unknown type name 'constexpr':
I have build problems on MacOS Sequoia 15.3.2, building from the main branch (commit 70a838f). I followed these instructions…

… and it almost worked, except I got four complaints about constexpr:

/home/griscom/git/bp5-main/src/pirate/rgb.c:472:5: error: unknown type name 'constexpr'; did you mean 'const_ioptr'?
  472 |     constexpr uint16_t value_diffusion     = 40u;
      |     ^~~~~~~~~
      |     const_ioptr

The problematic lines in src/prirate/rgb.c were:

static bool animation_angular_wipe(CPIXEL_COLOR color) {
    constexpr uint16_t value_diffusion     = 40u;
    constexpr uint16_t starting_value      =  0u;
    constexpr uint16_t ending_value        = (value_diffusion * 4u) + 256u;
    constexpr uint16_t default_frame_delay =  1u;

Changing each constexpr to const fixed it, and my build completed. (Big thrill when I installed and confirmed my customized version of the firmware, but perhaps I’m easily amused…)

Except for src/printf-4.0.0/test/catch.hpp, these are the only constexprs in the codebase. I saw PR 228 which mentioned enabling C++23 for better constexpr support, and I confirmed I was using the results, but it didn’t help me.

I don’t see that this change harms performance at all (they’re still constants, and can be evaluated at compile time). Would you accept a PR that removed the constexprs?

Issue opened by: dtgriscom

2

Hey!

This has become a common issue so maybe we need to do something about it.

We recently updated to C23 that has the constexpr feature. It requires the arm-gcc compiler version 13+. I use 14 on the build server now, and 13 for local development.

In terms of changing the constexpr - we would need @henrygab to weight in on that as we wanted to use it in the LEDs layer and maintains it.

Comment by: DangerousPrototypes

3

Can we detect the C version and throw an “newer arm-gcc needed” error? Or even change the const/constexpr based on detected C version?

I did a quick check and didn’t see anything obvious. I did add a note and link to latest GCC on the thread mentioned above.

4

Ah: am I right that the instructions I used specify gcc-arm version 10.3, causing the problem? Is there a source for a more recent gcc-arm? (I can’t find it on https://developer.arm.com/ …)

Having an official building.md document that specifies the complete build instructions, including a recent-enough gcc-arm, would be a great solution.

Comment by: dtgriscom

5

That said, avoiding recently-added code syntax that doesn’t help much (perhaps including codeexpr) would be a useful principle. That, or specifying clearly that the project requires C++23.

Comment by: dtgriscom

6

I made this a public thread in the forum to discuss solutions.

This is a super recent change. Documentation is getting a complete update right now, dreg is pushing broken link fixes right now. I’ll make sure to move and update the stuff you found in the forum to the new docs.

Comment by: DangerousPrototypes

7

I think this should be possible in CMake. Try something like this:

if (CMAKE_COMPILER_IS_GNUCC AND CMAKE_CXX_COMPILER_VERSION VERSION_LESS 14)
    message(FATAL_ERROR "At least GCC version 14 required")
endif()
1 Like
8

I’m disappointed that CMakeFiles.txt (which lists C23 as the required standard) is not enforcing the requirement:

Right now, GCC 13 is required, which is one revision back from the latest main version release (GCC 14). That said, I will submit a PR to remove the constexpr … maybe I’ll change it to a local enum.

Better to reduce pain, than force the upgrades?

2 Likes
9

I don’t have a super strong opinion, but it has cropped up a few times since the change. So either we need a work around, or to update all docs instances that show the earlier version. Or a warning.

10

I got around to upgrading my daily driver to Ubuntu 24.04. It’s now running gcc 13:

┌──(matty💊s76)-[~/data/projects/BusPirate5-firmware]
└─$ /usr/bin/arm-none-eabi-gcc --version
arm-none-eabi-gcc (15:13.2.rel1-2) 13.2.1 20231009
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Now, there’s just one build error; related to building a c++ file in the pico SDK:

BusPirate5-firmware/build_rp2040/_deps/pico_sdk-src/src/rp2_common/pico_cxx_options/new_delete.cpp:11:10: fatal error: cstdlib: No such file or directory
   11 | #include <cstdlib>
      |          ^~~~~~~~~
compilation terminated.

I don’t normally use cmake; I’m just a Makefile kind of guy (or bitbake or …). Anyway, any ideas on that? I’ll keep digging, but thought I’d just throw it out there.

Thanks again,
Matt

1 Like
11

I’m saying cmake, because I wonder if it’s trying to compile the c++ file with GCC instead of g++. It looks like CMake file is specifying g++ for .cpp files, but I’m not sure

1 Like
12

Reverted breaking changes.

Comment by: DangerousPrototypes

13

Ok, here’s the actual root cause of the issues (at least the issues I had). At least for Ubuntu 24.04, the gcc-arm-none-eabi package doesn’t install c standard lib includes and files for cross-compiling c++.

So, if you are running in Ubuntu and have installed/upgraded to 24.04, and get a build error telling you that cstdlib was not found, you need to install another package:

$ sudo apt install libstdc++-arm-none-eabi-newlib

That will fix things up and get you going :slight_smile:

3 Likes