Category: C++

solving a clang++ compiler problem on linux mint 22.1

whbeebe

During my initial setup of Linux Mint on the Samsung Series 7, I installed the Flutter toolkit ( https://docs.flutter.dev/get-started/install/linux ). Flutter has additional application requirements, one of which is Clang. So I installed all the additional requirements, then installed Visual Studio Code, then within VSCode I installed Flutter plugin.

Note that I did not install support for Android (Android SDK and Android Studio) nor the Web (via Chrome). All I’m doing is writing Flutter desktop applications.

The Flutter plugin within VSCode automates quite a lot. Using the VSCode Command Palette, you can create an initial Flutter application (Flutter: New Project) that will create skeleton code and build files that compiles and runs the graphical equivalent of hello, world.

Visual Studio Code with the Flutter plugin and an initial Flutter application, running that application in debug mode.

As you can see, the Flutter tools for both the framework and the VSCode plugin provide an effortless on-ramp to developing applications. Creating the start of an application is ridiculously easy, and it’s capable of building and executing from the get-go. One feature this has and I use quite a lot is hot reload. When I make changes to the code, when I save the changes they’re rebuilt and the running application restarted immediately showing those changes. That’s why I use this setup.

Sample Flutter application running on the desktop.

And here is the initial application’s extremely simple desktop window. When this works well, it’s a little like magic.

Unfortunately I ran into a problem where Clang, one of Flutter’s dependencies, could not link a C++ application that is part of the Flutter application. The error message reported by the Flutter tooling was (with much superfluous reporting snipped away):

.../usr/bin/ld: cannot find -lstdc++: No such file or directory...

This really annoyed me because I have this same setup on my other Linux Mint system, the UM250. With a bit of googling I discovered what was wrong, and how I’d accidentally side-stepped the issue on the UM250. I solved the problem on the Series 7 with sudo apt install libstdc++-12-dev. After that the Flutter tool chain just worked.

Why didn’t I see this issue on the UM250? Because I’d installed gcc/g++ version 12 to support another small project I was working on. On the UM250 I have both versions 11 and 12. Then when I later updated an older installation of Flutter and ran the same simple tests, everything worked there as well. I don’t intend to install gcc/g++ version 12 on the Series 7 as there is no need.

What I don’t understand is how Clang and GCC got out of sync on Linux Mint 22.1. The version of Clang installed is version 14, and requires libstdc++-12. Unfortunately Linux Mint 22.1 installs GCC version 11, which means that if you wanted to build with Clang you’re out of luck unless you know of Clang 14’s dependencies.

successful build and flash of esp32-c6-devkitc-1

whbeebe

I managed to order three of the ESP32-C6-DevKitC-1 developer boards from the Espressif store on Amazon. They’ve been advertised since mid-2022, and where-ever I went to try to buy them, they were advertised as out of stock. Finally I stumbled onto them on Amazon, and grabbed three examples. They arrived at my home earlier this week. They had to wait until today before I could sit down and begin to work with them.

These are not supported in any existing release of Espressif’s ESP-IDF. I had to clone from the master, or trunk, of their GitHub repo. This is what I used to perform that clone:

git clone --recursive https://github.com/espressif/esp-idf.git esp-idf-main

Once cloned I installed the ESP-IDF software and enabled the development environment I then moved into my wifi-scan folder that I’d migrated to ESP-IDF V5, and ran the following:

idf.py --preview set-target esp32c6

You have to run --preview for everything to be properly set up for the build. After that you can run a regular idf.py build, followed by the flash and monitor commands. You will need to do this before the boards will work. Out-of-the-box the boards, when powered up via USB-C, will immediately go into an endless boot loop because they’re flashed with the wrong code.

Here’s a small portion of what I saw on successful boot after a successful flash.

...ESP-ROM:esp32c6-20220919Build:Sep 19 2022rst:0x1 (POWERON),boot:0xc (SPI_FAST_FLASH_BOOT)SPIWP:0xeemode:DIO, clock div:2load:0x4086c510,len:0xd3cload:0x4086e610,len:0x2a64load:0x40875720,len:0x1790entry 0x4086c510I (23) boot: ESP-IDF v5.1-dev-3462-g045163a2ec 2nd stage bootloaderI (24) boot: compile time Feb 17 2023 13:48:04I (24) boot: chip revision: v0.0I (28) boot.esp32c6: SPI Speed  : 40MHzI (33) boot.esp32c6: SPI Mode   : DIOI (38) boot.esp32c6: SPI Flash Size : 2MBI (42) boot: Enabling RNG early entropy source...W (48) bootloader_random: bootloader_random_enable() has not been implemented yet...

Here’s some interpretation of those output lines. Line 2 shows that it’s an ESP32-C6 due to the boot ROM on the chip. Line 11 says it was built with ESP-IDF v5.1-dev. I cloned that specific tag, but it won’t support ESP32-C6. You have to use master. I found that a little concerning as the README says that ESP-IDF v5.1, when it’s formally released, is supposed to support the ESP32-C6 device. Oh well.

Everything else seems to be behaving normally, especially support for C++20 in the tool chain. This chip is also supposed to support Zigbee, but I haven’t researched that bit yet. Another goody to check out later.