esp32-c3 linker errors, project works fine on windows

[Unreal-Dan]

Describe the problem

My project randomly started failing it's CI on github, which uses linux and arduino-cli to build the project.

When building the project on windows with arduino IDE everything works fine, and previously on linux the CI would build just fine.

But... Now, when building my project with arduino-cli on linux I receive these errors:

/home/null/.arduino15/packages/esp32/tools/esp-rv32/2302/bin/../lib/gcc/riscv32-esp-elf/12.2.0/../../../../riscv32-esp-elf/bin/ld: warning: cannot find entry symbol _start; defaulting to 0000000000010074
/home/null/.arduino15/packages/esp32/tools/esp-rv32/2302/bin/../lib/gcc/riscv32-esp-elf/12.2.0/../../../../riscv32-esp-elf/bin/ld: /tmp/ccnHrGG8.o: in function `.L0 ':
/mnt/c/Users/danie/source/repos/VortexTestingFramework/VortexTestingFramework/VortexEngine/VortexEngine/appmain.cpp:5: undefined reference to `VortexEngine::init()'
/home/null/.arduino15/packages/esp32/tools/esp-rv32/2302/bin/../lib/gcc/riscv32-esp-elf/12.2.0/../../../../riscv32-esp-elf/bin/ld: /tmp/ccnHrGG8.o: in function `main':
/mnt/c/Users/danie/source/repos/VortexTestingFramework/VortexTestingFramework/VortexEngine/VortexEngine/appmain.cpp:7: undefined reference to `VortexEngine::tick()'
collect2: error: ld returned 1 exit status
/home/null/.arduino15/packages/esp32/tools/esp-rv32/2302/bin/../lib/gcc/riscv32-esp-elf/12.2.0/../../../../riscv32-esp-elf/bin/ld: warning: cannot find entry symbol _start; defaulting to 0000000000010074
/home/null/.arduino15/packages/esp32/tools/esp-rv32/2302/bin/../lib/gcc/riscv32-esp-elf/12.2.0/../../../../riscv32-esp-elf/bin/ld: /tmp/ccqbrwP3.o: in function `setup()':
/mnt/c/Users/danie/source/repos/VortexTestingFramework/VortexTestingFramework/VortexEngine/VortexEngine/VortexEngine.ino:7: undefined reference to `VortexEngine::init()'
/home/null/.arduino15/packages/esp32/tools/esp-rv32/2302/bin/../lib/gcc/riscv32-esp-elf/12.2.0/../../../../riscv32-esp-elf/bin/ld: /tmp/ccqbrwP3.o: in function `loop()':
/mnt/c/Users/danie/source/repos/VortexTestingFramework/VortexTestingFramework/VortexEngine/VortexEngine/VortexEngine.ino:14: undefined reference to `VortexEngine::tick()'
collect2: error: ld returned 1 exit status

Using library FastLED at version 3.6.0 in folder: /home/null/Arduino/libraries/FastLED

Used library Version Path
FastLED      3.6.0   /home/null/Arduino/libraries/FastLED

Used platform Version Path
esp32:esp32   3.0.4   /home/null/.arduino15/packages/esp32/hardware/esp32/3.0.4
Error during build: exit status 1
make: *** [Makefile:52: build] Error 1

The linker errors are for basic function calls in setup/loop:

#include <Arduino.h>

#include "src/VortexEngine.h"

void setup()
{
  if (!VortexEngine::init()) {
    // uhoh
  }
}

void loop()
{
  VortexEngine::tick();
}

This same code builds fine in arduino IDE on windows, and it was working fine then just randomly broke:

The change that made it break was a simple Doxygen file change, not even related to code, and the CI for the build started failing after that.

I can reproduce it locally on my linux, and I'm not sure where the problem is so I'm coming here.

To reproduce

I guess you could try and build my project, I don't have a minimally reproducible example. Let me know if you want commands to build the project.

Expected behavior

It builds

Arduino CLI version

arduino-cli Version: 1.0.4 Commit: a0d912d Date: 2024-08-12T13:42:36Z

Operating system

Linux

Operating system version

Ubuntu 20.04.1 LTS

Additional context

No response

Issue checklist

• I searched for previous reports in the issue tracker
• I verified the problem still occurs when using the nightly build
• My report contains all necessary details

[cmaglie]

Could you provide a link to the project and to the failing CI?
Can it be that the CI downloaded a different version of the esp32 platform than the one installed locally in your system?

The change that made it break was a simple Doxygen file change

Probably the failure is not due to a change in the code but to an external factor.

I guess you could try and build my project, I don't have a minimally reproducible example. Let me know if you want commands to build the project.

Yes, actually if you could provide a link to the failing CI we may try to fork it and try to debug it.

[cmaglie]

Ah I see that you can reproduce it locally, (sorry I read it too quickly), then yes, please provide a minimal example to reproduce it.

[Unreal-Dan]

So I just deleted all the files in my project and had nothing but 2 files: the main .ino and a secondary cpp.

I had the setup/init I show above and some empty functions for the VortexEngine::init/tick in the other file. I was able to reproduce it like that.

But then I tried removing things from the Makefile and I found when I remove --build-property compiler.cpp.extra_flags for my -D flags suddenly it seems to work fine.

I use this to pass my version number and -D flags to the compiler.

my makefile:

build:
    $(ARDUINO_CLI) compile --fqbn $(BOARD) $(PROJECT_NAME) \
        --config-file $(CONFIG_FILE) \
        --build-path $(BUILD_PATH) \
        --build-property compiler.cpp.extra_flags="$(DEFINES)" \
        --build-property compiler.c.extra_flags="$(DEFINES)"

Specifically the last lines, when I remove those it seems to work but when they are present it seems to cause issues:

        --build-property compiler.cpp.extra_flags="$(DEFINES)" \
        --build-property compiler.c.extra_flags="$(DEFINES)"

I use this to pass the -D flag for some constants I want to define in the build

[per1234]

Hi @Unreal-Dan

I found when I remove --build-property compiler.cpp.extra_flags for my -D flags suddenly it seems to work fine.

Unfortunately the "esp32" boards platform developers have unnecessarily used the compiler.cpp.extra_flags property internally in the platform:

https://github.com/espressif/arduino-esp32/blob/3.0.4/platform.txt#L69

compiler.cpp.extra_flags=-MMD -c

When you use the --build-property flag to override the property with your -D flags, you cause the loss of the -MMD -c flags from the compilation command. If you don't want your use of --build-property to have this side effect, you must make sure to include those flags in your definition of the compiler.cpp.extra_flags property. Note that the situation is the same for the compiler.c.extra_flags property.

The --build-property flag is a very advanced and powerful feature of Arduino CLI. You should only use it if you have a very good understanding of the platform of the boards you are using it with.

You can report the abuse of the extra_flags properties by the "esp32" boards platform to their issue tracker.

We are tracking the need to do a better job of encouraging platform developers to provide a set of properties for the exclusive use of the platform user here: #846

[Unreal-Dan]

Ah wonderful, that fixed it and it isn't a big deal to solve.

I'll keep an eye on this, thanks