A Fatal Error I Don't Understand ( section type conflict with 'Codec_gain')

econjack

Well-known member
I.m using Teensy 4.1 under Win 10 Home with 32 Gb of memory using IDE 2.3.3. I get the following error message:
==================
D:\AlsRevisedEd4\20WSoftware\SDT-mainBill\SDT-mainBill.ino: In function 'Splash':
C:\Users\User\AppData\Local\Arduino15\packages\teensy\hardware\avr\1.59.0\libraries\Adafruit_GFX/Fonts/FreeSansBold24pt7b.h:782:15: error: 'FreeSansBold24pt7b' causes a section type conflict with 'Codec_gain'
782 | const GFXfont FreeSansBold24pt7b PROGMEM = {
| ^
D:\AlsRevisedEd4\20WSoftware\SDT-mainBill\SDT-mainBill.ino:2035:6: note: 'Codec_gain' was declared here
2035 | void Codec_gain()
| ^
lto-wrapper.exe: fatal error: C:\Users\User\AppData\Local\Arduino15\packages\teensy\tools\teensy-compile\11.3.1/arm/bin/arm-none-eabi-gcc returned 1 exit status
compilation terminated.
c:/users/user/appdata/local/arduino15/packages/teensy/tools/teensy-compile/11.3.1/arm/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/bin/ld.exe: error: C
collect2.exe: error: ld returned 1 exit status
Multiple libraries were found for "Adafruit_MCP23X17.h"
Used: D:\AlsRevisedEd4\20WSoftware\libraries\Adafruit_MCP23017_Arduino_Library
Not used: C:\Users\User\AppData\Local\Arduino15\packages\teensy\hardware\avr\1.59.0\libraries\Adafruit_MCP23017
Multiple libraries were found for "Adafruit_I2CDevice.h"
Used: D:\AlsRevisedEd4\20WSoftware\libraries\Adafruit_BusIO
Not used: C:\Users\User\AppData\Local\Arduino15\packages\teensy\hardware\avr\1.59.0\libraries\Adafruit_BusIO
Multiple libraries were found for "Adafruit_GFX.h"
Used: C:\Users\User\AppData\Local\Arduino15\packages\teensy\hardware\avr\1.59.0\libraries\Adafruit_GFX
Not used: D:\AlsRevisedEd4\20WSoftware\libraries\Adafruit_GFX_Library
exit status 1

Compilation error: exit status 1
===============

Obviously I'm most concerned what I'm doing wrong to generate the fatal error. Any help would be appreciate.
 
You seem to have a bunch of library conflicts there, in some cases the compiler is using the teensy libraries and other cases it isn't. Why do you have other copies of libraries that are included in the Teensy installation?
 
These section type conflict errors happen for a couple reasons. Can't see enough of your code to say why.

Briefly, #1 use of PROGMEM on functions (it's meant for data) or FLASHMEM on data (it's meant for functions). It's kind of a silly limitation in the compiler, that functions and variables need a different section name for essentially the same thing, but that's exactly the reason why we have both PROGMEM and FLASHMEM.

#2 is use of PROGMEM or FLASHMEM on data which is pointers which aren't properly const. For example:

Code:
int myinteger = 5;
const int *mypointer = &myinteger;

You might think you could use PROGMEM on this pointer, but it can cause a section type conflict. The "const" here means you promise not to use the pointer to alter whatever memory it's referencing. You are allowed to change which integer the pointer references. To allocate this sort of pointer in PROGMEM, you need to use const to say the pointer will never be changed to point anywhere else, like this:

Code:
int myinteger = 5;
int * const mypointer = &myinteger;

If you also want to promise never to alter the reference memory, this use this:

Code:
const int myinteger = 5;
const int * const mypointer = &myinteger;

For putting pointers in PROGMEM, what matters is whether the pointer is forever const regarding what memory it actually references.

Whether this applies to your program, I don't know since I can't see enough of your code. But I put the time into this answer anyway in hopes it might help. If not, please understand how important sharing a complete picture of your code is for answering these sorts of difficult questions.
 
@jmarsh. The various packages (arduino, STM32, ESP32, and Teensy) have their own folders for libraries. I'm very careful about using brackets (<>) and double-quotes on the proprocessor directives. The search path for "" should be Project Directory then the default after the packages directory. Brackets should just search the default path. However, it appears that the arduino package path is also searched if the proper library is not found. I do not know if this is Standard C behavior.

@Paul: I know very well how important the source code is in tracking things down, but it's pretty large (390K) spread over 20 files and didn't know which source code was appropriate. The code is still the same Software Defined Receiver code I've been managing for the past several years. I think what I'll do is go back and look at the PROGMEM and FLASHMEM qualifiers to see if those are being used correctly in the code.

Thanks for your help!
 
Back
Top