PlatformIO Community

Multiple definitions warning - cant fix it

#1

Hi There,

I guess I unfortunately updated a lib or a board and now I got this multiple definitions warning I cant solve.

Linking .pio\build\ttgo-t-beam\firmware.elf
c:/users/marcel/.platformio/packages/toolchain-xtensa-esp32/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld.exe: C:\Users\Marcel\.platformio\packages\framework-arduinoespressif32\tools\sdk\esp32\lib\libpp.a(hal_mac.o): in function `hal_init':
(.text.hal_init+0xb4): multiple definition of `hal_init'; .pio\build\ttgo-t-beam\libefd\libMCCI LoRaWAN LMIC library.a(hal.cpp.o):D:\CLOUD\OneDrive\ARBEIT\TraveKom\Sensortestfeld\Umweltdatenerhebung\Breiche\Citizens_Science_Workshop\Software\ttgo_envi_sens_SA/.pio/libdeps/ttgo-t-beam/MCCI LoRaWAN LMIC library/src/hal/hal.cpp:416: first defined here
collect2.exe: error: ld returned 1 exit status
*** [.pio\build\ttgo-t-beam\firmware.elf] Error 1
======================================================================================== [FAILED] Took 44.40 seconds ========================================================================================
The terminal process "C:\Users\Marcel\.platformio\penv\Scripts\platformio.exe 'run', '--environment', 'ttgo-t-beam'" terminated with exit code: 1.

So I would guess, that hal_init is now also implemented in the esp32 libpp. as well?
I tried to delete the folder but it gets reinstalled on compiling.

Can someone give me a hint?

#2

Yes, a name conflict of in the MCCI LoRaWAN library and the ESP32 base libraries with both of them wanting to name a function “hal_init()”. Try fixing the error by copying the library folder into your lib/ folder and renaming the hal_init() function there (with all of its usages, but should be relatively few, example).

2 Likes
#3

Thanks! That solved the problem. I was hoping I could revert the update of the esp32 base library.

Unfortenately I now get core panic errors due to an ISR that worked fine before :thinking:

#4

Marked all ISRs and functions called from the ISR with the IRAM_ATTR?

#5

If it will not work with the latest Arduino core, you can always revert back to Arduino-ESP 1.0.6 by overriding platform = espressif32@3.5.0 in the platformio.ini.

#6

of course I did not :man_facepalming:
Thank you so so much for pointing me on that little detail!
I changed my code acordingly.

Nevertheless I got ISR errors. Should have something to do mith the new ESP32 Lib update. If I revert to 3.5.0. ISR and the rest of the programm runns fluently… :thinking:
Im using a t-beam - maybe it has somethin to do with that…

#7

Hardware should not be a problem. I think it’s solely in the software with this one.

Do you have more details on which ISR crashes with what backtrace (monitor_filters = esp32_exception_decoder and build_type = debug in the platformio.ini) and what code you’re running / where these ISRs are implemented? If it’s in a lib there might be an update available?

#8

Thanks a lot for your help.
Well I could just say that after reverting to 3.5.0. the board doesnt crash anymore as it was before the update.
The ISR that crashes is my own. I will go into debug tomorrow and see if I can get more information out of that.

The code is mostly my own but it heavily uses the LMIC LoRA Lib.

#9

I can confirm the solution in post #2 resolved the same error for me using an SparkFun LoRa Gateway - 1-Channel (ESP32) with platformIO in vscode using the arduino framework. Thankyou very much!

#10

For completion, the issue in the original library is at

but authors declared this as a “wont-fix”.

The fix suggested in the last post of that issue can be implemented in PlatformIO using

build_flags = 
   -Dhal_init=LMICHAL_init

in the platformio.ini.