Linker error: dyn mem mis-match true!=false

[allenhuffman]

I keep getting myself in a spot where my builds stop working with an odd linker error:

Linking to FlashLogger.hex on 17-Jun-19 at 13:24
*** Error 146 "C:\(path here)\$linker.c" Line 5(8,14): Import error dyn mem mis-match true!=false
*** Error 146 "C:\(path here)\$linker.c" Line 5(8,29): Import error
2 Errors, 0 Warnings.
Build Failed.

I found a few references to this in the forum, but nothing that seemed to explain to me what causes it.

I am doing a multi-file test program with FOUR .c files. I do not understand the compiler architecture enough yet to understand what's going on. I suppose I'll learn more once I've been using it more than a week.

Anyone have any tips on where I can look? I did not find anything helpful in the Help file for this linker (?) error.

Thanks!

[dluu13]

What IDE are you doing this in?

If you are doing this in MPLAB then you will need to put those .c files under "header files" in your project. Then you will need to #include the .c files in your main file.

At least this is what I think is going on.

[PCM programmer]

It seems to me that you're trying to do multiple advanced things while
still a newbie on CCS. That's not a good idea.

Regarding your errors, see this thread. One guy at the end says
he has a solution.
http://www.ccsinfo.com/forum/viewtopic.php?t=45074
But if I were you, I would just not do this stuff now.

[allenhuffman]

[allenhuffman]

[dluu13]

I use plenty of c files as well. However, CCS is a single pass compiler so then you have to #include the .c files as the top of your main c file rather than just the .h files.

If you look at the examples in the examples folder of the CCS installation, you can find some instances of including the .c files.

[allenhuffman]

[PCM programmer]

Are you using "Multiple Compilation Units" ? That's an advanced topic.
The standard way to use CCS is to have only one file (your main .c file)
listed in the project files. Then add other files by using #include
statements in your main .c file. This method is pretty reliable.

[allenhuffman]

[allenhuffman]

For future reference... I've been making a list of things that can cause this, and will add them here:

Using the #include <time.h> files will include <stdlibm.h> and cause this.
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ?

[Ttelmah]

What is strange though is that "stdlibm.h", should already be adding
the #USE DYNAMIC_MEMORY.

This is _required_ if you are using the dynamic memory functions, unless
you are manually setting the parameters for this. In stdlibm.h, we have:

[allenhuffman]

[Ttelmah]

Yes.

I think they mean that #USE DYNAMIC_MEMORY, needs to be present in
every compiled 'part'. So each 'compilation unit' must have it in. So each .o
file must have been compiled with this setting.
So each 'file' here is each .o file, not each file of your project.
It makes total sense once you think about how dynamic memory is handled.

[allenhuffman]

UPDATE:

[afk_pic]