This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Compiler (TI for Tiva) reports bizarre errors but still appears to produce a working binary image



I copied my working build off to another drive and downloaded everything out of SVN on Friday.  I am using SVN outside of CCSv6 so that is not an issue. I compile my files and several give me errors such as:

Field 'address' could not be resolved

Here is the line of code:

      modbus_2_bpp_msg.address[i] = address + i;

Here is the enum definition in the header file:

struct modbus_mailbox_msg
{
   unsigned char number_of_data_elements;
   unsigned char data_type;
   unsigned short address[8];
   unsigned short data[8];
};

Here is the data declaration in the source file where the error is reported:

struct modbus_mailbox_msg modbus_2_bpp_msg;

So, to be sure that the header file is being handled, I put a #error directive in the header file immediately before the struct definition and I get an error from the #error directive.  That means the compiler is seeing the header file. I look at the console output and just see the warnings from the problems between errno.h and serrno.h, so the compiler is actually producing proper output.

I also get errors such as:

Symbol "AF_INET' could not be resolved.

SInce I am including the network headers from NDK, that seems very unlikley. I also get Symbol could not be resolved for my own #defined values.

It seems to me that what is happening is that the C parser that is part of Eclipse is somehow confused and is either pulling a header from an old directory or some other project configuration file.


I used WinMerge and compared all of the files between a working version of the project and the new one I just checked out of SVN. There are *ZERO* differences in the project files.


How do you debug something in Eclipse getting terribly confused?

  • Most likely this has nothing to do with the compiler itself. You are correct that Eclipse has a built-in C parser for various features like code highlighting, etc, but those features do not invoke the actual compiler. We should probably move this thread to the CCS forum.
  • OK. Let me know when it is moved and any ideas you have on which Eclipse file is getting hosed. Does this mean that there is a file somewhere that needs to be stored in SVN along with the source and project files that got missed? As a data point, a coworker checked out the project into a clean directory and does not see this issue.
    The XDC system and Eclipse make life *incredibly* difficult to move projects between machines (or even to a new location on the same machine). Cloning a project is basically impossible.
  • I got rid of some warnings. I missed that one of my include warnings was Include directory not found. I had "${workspace_loc}/include". This *must* be upper case ("${WORKSPACE_LOC}/include"). However, Eclipse is still barfing on a lot of symbol references that come from include files in that directory. For some reason the path is resolved correctly for the compiler even if WORKSPACE_LOC is lower case.
  • I'm a little confused on the context that is present when the errors occur.  If the errors occur during the build, then I suggest you add the compiler build option --gen_acp_raw.  Read about it in the ARM compiler manual.  You'll see that it is useful in seeing problems with include files and other preprocessing.  If the errors occur while editing the code, or some other time, then that is a problem with CCS directly.

    Thanks and regards,

    -George

  • George:
    Apologies for being unclear. After seeing the post from Archeologist, I confirmed that the errors are coming from the parser in the IDE rather than from the compiler. I have gen_acp_raw selected so we know the compiler is doing just fine. Indeed, the project compiles and links without errors and runs once you tell the debug launch dialog to do it even with "errors".

    I have done clean and rebuild numerous times just to try to convince CCS that things have changed. I have also closed and re-opened CCS. I found a variable or two that were left over from when we cloned the project. That seems to have removed the problems with the TI include path. Now I only see issues with my own header files. It would appear that CCS is simply not finding my include path even though it is correct under Projects/Properties/build/ARM compiler/include options.

    Here is what my tree looks like:
    Workspace (Workspace at root of drive)
    include (shared include files across the set of projects)
    library1 ( a shared library directory)
    library2 ( the shared BSP library directory)
    bootloader ( our custom boot loader application)
    main_application ( our actual application)
    modbus_server (a copy of our modbus source)

    I changed the occurrences of '#include "project.h" ' in library1, main_application, and main_application/modbus_server to "../include/project.h" or "../../include/project.h" as appropriate and the errors went away.

    So, the question is: where is that include path stored in .project,.cproject, or .csproject or is it in yet another configuration file?

    Why does CCS find it when building the compiler command but not while parsing the files in the IDE?

    Another question: when I had the wrong case for the include path, why did the warning say "cannot find include path" but not go to the place where the include path is defined when double clicked? Something obviously knows it cannot find the project path.

    Thanks.

    Ray
  • Ray,

    It seems that you have confirmed that the project indeed builds fine, so the syntax errors are not from the compiler but from the indexer that comes built-in with CCS. There is a way to disable the indexer or control its settings. Please see this related thread on how to do that. Maybe you can give that a try at least to confirm that it is indeed what is generating the errors.

    You mentioned a co-worker being able to build the same project without those errors. Can you check his Indexer settings compared with yours? Also could you try re-importing your project into a clean new workspace, rebuilding it and see if the errors still appear?

  • Aarti:

    It was definitely the indexer.  I shut down last night after adding the "../include" in front of my file names (which eliminated the "errors").  It appears that just doing that was enough to convince CCS where to find the include files. I took the "../include" parts of the path back out after the errors went away and CCS seems quite happy now.

    I did not need to change the indexer settings, but I will keep that on the top of the list for "things that can go wrong" when you try to clone a project.

    One thing that would be really nice to have is a tool that will allow a user to clone a project into a new directory with a new name.  The hard part about doing that is understanding which files are necessary to dump in a blank project directory and which ones will just confuse CCS.

    After this post I will mark it as answered (if the web site will let me).

    Ray