Community
Participate
Working Groups
I have multiple projects in my workspace, where I very cautiously try to encapsulate & export my stuff using the export settings. So when I reference projects symbols and includes are automatically set. Since I updated to M5 I suddenly get symbol resolution errors all over the place. The symbols are all from other projects and I think that they are all typedef'ed enum's. Now, the compiler itself works like a charm and does not complain about anything (well it does but not about those symbols ;-) even when I set the weirdest warning levels. Also F3 and macro expansion does what it should do. Another thing that I don't quite get is the following: In project A I have a header that declares some global types and it also includes <stdint.h>. The libc is not being explicitely exported in the build settings and neither do I import it in the other projects. What I do though is, I #include my global type file which means stdint.h should be visible there too. And in fact the compiler gets it all right. It's again codan that is doing funny things. I might say that I have only tried with cross-compiler settings and each of my projects have more than one such build setting.
another thing that I've discovered is that error markers are getting refreshed only after changing to another EditorPart and returning back to the editor in question. All in all I must admit I find the indexer a beast that has always given me headaches :-(
Did you try reindexing? Your report is a bit vague to work with. If you can post reproducible example that would be useful. This could be bug 368045 or something different.
first of all, I switched back to a recent 8.0.0 maintenance version, which solved the issue for me. So there is definitely something wrong in the last milestone build. Maybe I try to explain again: Project A: * on the Include-Path: some cross-libc, /include(exported) * mytypes.h includes (stdint.h), uses uint8_t, declares typedef enum {TEST1, TEST2} x_t Project B: * reference to Project A in project settings -> /include from Project A appears in the include path * myfile1.c includes mytypes.h -> everytime I use x_t I get an error about "symbol TEST1 can't be resolved" * myfile2.c includes mytypes.h -> does not use any of the typedefs in mytypes.h but uses unit8_t -> now I get an error about uint8_t not being defined The compiler, on the other hand, runs smoothly and does not complain about any of the errors mentioned above. is that clearer now?
Do you still experience these issues with CDT 8.2 (Kepler)?
(In reply to comment #4) > Do you still experience these issues with CDT 8.2 (Kepler)? no, the problem seems to have vanished.
closing as it seems to resolve itself
