Maybe someone can explain a few quirks I noticed when converting a CW7.1 GUI project to a CW7.1 command-line based GNU Make environment using the command line compiler/assembler/linker:
1. In the project, several assembler source files carry an extension *.cw; the GUI accepts those without complaint; using the CL tools I get the warning:
### Command_Line_Tools/mwasmmcf.exe Driver Warning:# No file mapping matches '..\..\LLD-C\src\boot\startup\vectors.cw' # (unrecognized file contents or filename extension); treating as source # text
How can I prevent this warning?
2. In my medium-sized project (~2000 source files) I use 3 libraries to be linked together with the main application. When I compile-and-link using the CL tools, I get two unresolved linker warnings:
### Command_Line_Tools/mwldmcf.exe Linker Error:# Undefined : "__heap_addr"# Referenced from "init_default_heap" in C_4i_CF_StdABI_MSL.a### Command_Line_Tools/mwldmcf.exe Linker Error:# Undefined : "__heap_size"# Referenced from "init_default_heap" in C_4i_CF_StdABI_MSL.a
I've seen samples defining these items in the *.LCF file, but my code doesn't contain definitions for them, however, the GUI manages to produce a valid executable, without apparently defining them either. Is there some implicit definition from the GUI-side that I have to handle myself when using the CL?
3. When I perform a clean CL-build, building everything from scratch, I just get the two warnings from issue 2. If I do an incremental build, several but not all files are recompiled (dependency checking currently is limited), libraries are recreated. But curiously, the linker produces an additional set of unresolved references from another two files that aren't a problem for a full build. Yes, I know CW is using a positional linker, but I verified the linker instructions to be identical...
Is the linker implicitly updating a library if it already exists, leaving identical objects alone and appending changed objects again to the end?
TIA for any clarification possible.
Johan
