Bugzilla – Full Text Bug Listing
| Summary: | Built-in includes seem to be broken for Cross GCC | ||
|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | AK <kirsche40> |
| Component: | cdt-build | Assignee: | Marc-André Laperle <malaperle> |
| Status: | RESOLVED FIXED | QA Contact: | Andrew Gvozdev <angvoz.dev> |
| Severity: | blocker | ||
| Priority: | P3 | CC: | cdtdoug, czikus, exnadler, frederic.servant, idragoev, kalast, ma.shaikh, mail, malaperle, mario.pierro, rustysawdust, yangttak, yevshif |
| Version: | 8.0 | ||
| Target Milestone: | 8.3.0 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Bug Depends on: | 353786, 353890, 369887, 369888 | ||
| Bug Blocks: | |||
| Attachments: | |||
|
Description
AK
Created attachment 200807 [details]
Indexer marks correct occurrence
Indexer marks correct occurrence of ModelsMessage_t while some local EOFException e0.getMessage() is marked as Semantic Error "Method 'getMessage' could not be resolved". And EOFException is not highlighted in with green colour as known type.
Created attachment 200808 [details]
Indexer does not mark occurrence of variable and does not know std::endl
The indexer does not mark the occurance of variable e0 which is in scope of code block.
Created attachment 200809 [details] indexer knows std:endl but not the variable within local scope The indexer knows std:endl but not the variable within local scope. This behaviour is confusing because some lines later (see attachment https://bugs.eclipse.org/bugs/attachment.cgi?id=200808) also std::endl become unknown to the indexer. The screenshots are taken from the same source file. As you can see, the indexer does loose references to already known symbols (std::endl) and types/classes. In my opinion this is a blocking bug because CODAN and indexer become completely unusable. Created attachment 200822 [details]
indexer searches through paths to symbols which are not part of the project
The picture shows the dialog which is opend after marking "exception" in line 197 and pressing F3. I did not set up the path to /usr/include/c++/4.2/exception but it is shown in this dialog. It seems the indexer searches through paths to symbols which are not part of the project.
Created attachment 200824 [details]
Built-in includes example
You shouldn't need to set the include paths for your toolchain. When you build, they should be picked up by Scanner Discovery. Did you set the path to your toolchain in the Build Settings in the project properties? Once that's properly set for sure, I would try this:
1. Open project properties, C/C++ Build, Discovery. Press the "Clear" button for both GCC and G++ tools
2. Build project
3. Check that the built-in includes were picked up: In Project properties, C/C++ General, Paths and Symbols (see screenshot for example)
4. Re-index the project (Right-click on project, Index, Rebuild)
(In reply to comment #6) > Created attachment 200824 [details] > Built-in includes example > > You shouldn't need to set the include paths for your toolchain. When you build, > they should be picked up by Scanner Discovery. Did you set the path to your > toolchain in the Build Settings in the project properties? Once that's properly > set for sure, I would try this: > > 1. Open project properties, C/C++ Build, Discovery. Press the "Clear" button > for both GCC and G++ tools > 2. Build project > 3. Check that the built-in includes were picked up: In Project properties, > C/C++ General, Paths and Symbols (see screenshot for example) > 4. Re-index the project (Right-click on project, Index, Rebuild) I should add: 0. Remove the include paths you entered manually (/opt/eldk/ppc_82xx/usr/include/, etc) (In reply to comment #7) > > Did you set the path to your toolchain in the Build Settings in the project > > properties? Once that's properly set for sure > > Yes, I tried this without success. It seems I am not the only one with CODAN problems: http://www.eclipse.org/forums/index.php/t/216821/ > > 1. Open project properties, C/C++ Build, Discovery. Press the "Clear" button > > for both GCC and G++ tools I did this and adding other necessary project dependencies like a static library created by another of my projects over "project properties --> C/C++ Gerneral --> Paths and symbols". > > 2. Build project Build succeeds. > > 3. Check that the built-in includes were picked up: In Project properties, > > C/C++ General, Paths and Symbols (see screenshot for example) > There are some differences. You are using mingw in Windows environment. I am using ELDK under Linux. In addition I refer to other projects in my workspace. > > 4. Re-index the project (Right-click on project, Index, Rebuild) > The errors do not vanish. Seriously after restarting eclipse I can not remove them from "Problems view" because the option "Delete" is greyed out even if I select only one error message. I had to close and reopen the project to get rid of the errors. > I should add: > 0. Remove the include paths you entered manually > (/opt/eldk/ppc_82xx/usr/include/, etc) I did this without any change in the result. By doing the complete procedure maybe I detected something interesting: If I run CODAN manually, I will got no error after CODAN has finished its work. If I let pass few seconds after this I get all errors again. (In reply to comment #8) > Yes, I tried this without success. It seems I am not the only one with CODAN > problems: > http://www.eclipse.org/forums/index.php/t/216821/ So far, I don't think Codan is the problem. Looks like Codan showing errors is a symptom of a problem with built-in includes discovery with the Cross GCC toolchain. Codan itself doesn't deal with include paths, the checkers under the category "Syntax and Sematic errors" just reports the problems found by the indexer (except for Abstract class cannot be instantiated). (In reply to comment #8) > The errors do not vanish. OK. I installed CDT 8.0.0, the eldk 3.0 and I'm using the ppc_82xx target too so we should be able to get to the bottom of this. I created an Executable, Cross Compile Project. I set the prefix (ppc_82xx-) and path inside the wizard. I added a hello world cpp file, built and it worked: the built-in includes were only from my ppc_82xx folder and I did not get errors from Codan. But I think I may have found the source of the problem: the command used for discovery doesn't get updated when you change the prefix in the build settings. So can you try this? 1. Again, open project properties, C/C++ Build, Discovery Options 2. Verify that the "Compiler invocation command" is ppc-linux-gcc (for Cross GCC) and ppc-linux-g++ (for Cross G++) 3. If they were plain g++ and gcc and you had to change if the last step, then do the "Clear" thing again. Build. Check that the built-in includes look good, then re-index. I also tried updating to cdt-release build 133 to try static lib and shared lib. Since they don't have the prefix+path page in the wizard, the "Compiler invocation command" doesn't get set in Discovery Options in addition to the Prefix and Path not being set in Build, Settings. If I configure both the Discovery Options and Build/Settings manually, then it works. I've switched back to Eclipse Helios SR2, because I have to release my project on schedule. After this I will again set up the Indigo environment. This will happen over the next few days. After this I will give you new feedback. Sorry for the delay. Hi - i have encountered the same issue with Eclipse CDT Indigo. My current environment is - Windows Vista Ultimate JDK 6 Update 26 CYGWin with all packages. I am able to reproduce it by cleaning the entire systems first and then downloaded and installed the cygwin, download and extracted the current CDT Indigo and started it with eclipse.exe -clean command with new workspace. After starting the eclipse IDE i created a simple Hello world project, build it and everything was completed with any of these issues. Then i went on Eclipse->Help->Install New Software and selected "The Eclipse Project Updates - http://download.eclipse.org/eclipse/updates/3.7" to install JEE development tools (i develop code in both - C++ and Java) - it updated successfully but i the all the red line appeared with "symbol std could not be resolved". I suspected that JEE updated messed up my project settings so All i did to fix the issue is to restore build-in include project settings by clicking Restore Defaults and everything is normal now. Hi - i have encountered the same issue with Eclipse CDT Indigo. My current environment is - Windows Vista Ultimate JDK 6 Update 26 CYGWin with all packages. I am able to reproduce it by cleaning the entire systems first and then downloaded and installed the cygwin, download and extracted the current CDT Indigo and started it with eclipse.exe -clean command with new workspace. After starting the eclipse IDE i created a simple Hello world project, build it and everything was completed without any of these issues. Then i went on Eclipse->Help->Install New Software and selected "The Eclipse Project Updates - http://download.eclipse.org/eclipse/updates/3.7" to install JEE development tools (i develop code in both - C++ and Java) - it updated successfully but i the all the red line appeared with "symbol std could not be resolved". I suspected that JEE updated messed up my project settings so All i did to fix the issue is to restore build-in include project settings by clicking Restore Defaults and everything is normal now. I experience a very similar problem in Indigo running under Ubuntu 11.04 x64. After automatic discovery of paths, I get "std is ambiguous, candidates are ''". This makes all the future references to stl classes detected as errors by the code analysis. (In reply to comment #10) > I've switched back to Eclipse Helios SR2, because I have to release my project > on schedule. I'd be interested to know if you see a different set of built-in includes in Helios versus Indigo. Note that Helios did not report the semantic errors which can make it appear like it works better but it could be hiding the fact that the index has problems. In Indigo, if you turn off the Syntax and Semantic errors in the preferences (under Code Analysis) you should get the same behavior as Helios - the red lines will go away. If you are curious about the problems found by the indexer in Helios, you can optionally turn on the Syntax coloring for Problems in Preferences, C/C++, Editor, Syntax Coloring, Element: Code, Problem, tick the enable box. This will highlight problems in red but will not underline, create markers and offer description like CODAN does. The indexer also generates a report after an index build in the error log. I expect the results between Helios and Indigo to be similar if not better in Indigo. When setting up new projects, I look at the "unresolved names" percentage in the report. I try have it bellow 1% by making sure my Paths and Symbols in the project settings are accurate. But for that to even have a chance, built-in includes and symbols have to be correct. (In reply to comment #11) > Hi - i have encountered the same issue with Eclipse CDT Indigo. > ... > Then i went on Eclipse->Help->Install New Software and selected "The Eclipse > Project Updates - http://download.eclipse.org/eclipse/updates/3.7" to install > JEE development tools (i develop code in both - C++ and Java) - it updated > successfully but i the all the red line appeared with "symbol std could not be > resolved". This sounds like a different issue. Was the project using the Cross GCC toolchain or Cygwin GCC? Maybe Rebuilding the index would've fixed that (Right-click on project, Index, Rebuild). (In reply to comment #13) > I experience a very similar problem in Indigo running under Ubuntu 11.04 x64. > After automatic discovery of paths, I get "std is ambiguous, candidates are > ''". > This makes all the future references to stl classes detected as errors by the > code analysis. Do you use the Cross GCC toolchain? What does your built-in includes look like? If they look OK, try rebuilding the index (Right-click on project, Index, Rebuild). If that doesn't fix it... it's a long stretch but it might be an issue with the "File to index up-front" in the indexer, see bug 197989. To the people who voted for this bug, Do you have a problem with the built-in includes with the Cross GCC toolchain specifically? If so, I would like to hear more about it so I can reproduce the problem you have. I just want to make sure that people are not voting for or following this bug because they are seeing Codan errors for other reasons. If you are seeing errors and don't have wrong built-in includes with Cross GCC: First double check your Path and Symbols in your project settings, rebuild the index (Right-click on project, Index, Rebuild) then if that doesn't solve it, report a new bug. (In reply to comment #17) > To the people who voted for this bug, > > Do you have a problem with the built-in includes with the Cross GCC toolchain > specifically? If so, I would like to hear more about it so I can reproduce the > problem you have. > > I just want to make sure that people are not voting for or following this bug > because they are seeing Codan errors for other reasons. If you are seeing > errors and don't have wrong built-in includes with Cross GCC: First double > check your Path and Symbols in your project settings, rebuild the index > (Right-click on project, Index, Rebuild) then if that doesn't solve it, report > a new bug. Same thing here, I am using eclipse indigo with win 7 MinGW and cmake 2.8.6. I am getting errors about, for instance, <stdlib.h> while the header appears on the header list for my environment on the project tree. Also noticed that extern C blocks cause the indexer to erroneously issue warnings. (In reply to comment #18) > Same thing here, I am using eclipse indigo with win 7 MinGW and cmake 2.8.6. Do you use CMake to generate Eclipse projects? I don't think any CMake generator can generate projects with the Cross GCC toolchain. So doesn't sounds like this problem is related to the Cross GCC toolchain... maybe the generator has a problem? I noticed that projects generated with CMake look very different (in the properties and the project file) then the ones created by Eclipse itself. (In reply to comment #19) > (In reply to comment #18) > I noticed that projects generated with CMake look very different (in > the properties and the project file) then the ones created by Eclipse itself. Those are old 3.X CDT projects. CDT was kept backward compatible for those but we do not maintain that anymore. Somebody tell CMake guys that that kind of project is obsolete. Hi, here is what we have: Ubuntu Server 11.10 with Indigo and CodeSourcery Light toolchain. We have a solution that includes 4 projects. The projects are build and in the output windows we can see the files are generated - 3 libraries and one executable. However, opening a source file immediately produces number of errors like the one below: Type 'std::string' could not be resolved ConnectionPoint.cpp /Common line 95 Semantic Error We are using Cross GCC. Here are some settings from project's properties: C/C++Build: Discovery Options: Configuration-Wide, Compiler invocation command = arm-none-linux-gnueabi-gcc Settings: Cross Settings: Prefix = arm-none-linux-gnueabi- In Paths and symbols - nothing special for Includes. However there is no difference whether the compiler's paths are manually added in the includes or not, the result is just the same. I hope some can help in this issue, because it makes Eclipse unusable for cross compiling... Regards, (In reply to comment #21) > In Paths and symbols - nothing special for Includes. However there is no > difference whether the compiler's paths are manually added in the includes or > not, the result is just the same. What about the symbols? If discovery worked correctly you should see the built-in symbols. If both paths and symbols are correct, then you might be seeing a parsing problem like 197989. You could try a nightly build of 8.1 and see if that helps. http://download.eclipse.org/tools/cdt/builds/juno/nightly/ Also, do you have multiple configurations in your project? You could be seeing Bug 313944. (In reply to comment #21) > I hope some can help in this issue, because it makes Eclipse unusable for cross > compiling... You can disable Syntax and Semantic errors in the preferences, it doesn't affect compiling. It's in Project properties, C/C++ General, Code Analysis. (In reply to comment #10) > I've switched back to Eclipse Helios SR2, because I have to release my project > on schedule. After this I will again set up the Indigo environment. This will > happen over the next few days. After this I will give you new feedback. Sorry > for the delay. AK, do you have some time to try again with Indigo SR2? I would very much like to be able to reproduce the problem. Any help is appreciated! Sorry for the long delay. I had much more project pressure since my last post as expected... I installed Indigo SR2. I set up a new project. The Cross Toolchain is correctly detected. A build succeeds. If I ran a build on my old projects I got again the previously mentioned CODAN errors like "memset is ambiguous". But I think this comes from the issue that the wrong old toolchain paths still exists in the projects (/usr/include/c++/4.4 instead of /opt/eldk/ppc_82xx/usr/include/c++/3.2.2) and are not erasable over the UI. In addition I got a lot of false positives (the code compiles fine in Helios). For example: Symbol 'ObjectImpl' could not be resolved when I try to inherit from log4cxx::helpers::ObjectImpl. Maybe its the same or another error in CODAN. (In reply to comment #24) > Sorry for the long delay. I had much more project pressure since my last post > as expected... > > I installed Indigo SR2. I set up a new project. The Cross Toolchain is > correctly detected. A build succeeds. Thanks for your help! > If I ran a build on my old projects I got again the previously mentioned CODAN > errors like "memset is ambiguous". But I think this comes from the issue that > the wrong old toolchain paths still exists in the projects > (/usr/include/c++/4.4 instead of /opt/eldk/ppc_82xx/usr/include/c++/3.2.2) and > are not erasable over the UI. Would you mind attaching the .sc file for your project? It should be in workspace/.metadata/.plugins/org.eclipse.cdt.make.core/theProject.sc. Also, you mentioned in a previous comment that you referred to other projects. Is is possible that the other projects have the wrong includes? Could you attach the sc file from one of those projects as well? I made two project: one library which has /usr include paths and one executable which has /opt/eldk include paths and made it refer to the library project. Both contain files that include string.h. If I press F3 on strcmp, I do get the window with the 2 different references. But I don't get the CODAN errors. BTW, I noticed that your /usr path now shows 4.4, which version of GCC and Ubuntu do you use now? I'm on GCC 4.6.1/Ubuntu 11.10. > In addition I got a lot of false positives (the code compiles fine in Helios). > For example: Symbol 'ObjectImpl' could not be resolved when I try to inherit > from log4cxx::helpers::ObjectImpl. Maybe its the same or another error in > CODAN. I expect a lot of the false positives will disappear when the includes problem is fixed. (In reply to comment #25) > (In reply to comment #24) > Would you mind attaching the .sc file for your project? For this case I added the file czUtilities.sc. > Also, you mentioned in a previous comment that you referred to other projects. > Is is possible that the other projects have the wrong includes? Could you > attach the sc file from one of those projects as well? It does not matter. I attached a *.sc for a static library. The error comes from the issue mentioned below at the end of this message. > Both contain files that include string.h. If I press F3 on strcmp, I do get > the window with the 2 different references. But I don't get the CODAN errors. As you can see in the attached screenshot (czUtilitiesCODAN-error.png) I still get CODAN errors. > BTW, I noticed that your /usr path now shows 4.4, which version of GCC and > Ubuntu do you use now? I'm on GCC 4.6.1/Ubuntu 11.10. > I switched forth ad back my Linux Distribution (Ubuntu > Fedora > Debian). :-) Currently I am using ELDK 3.0 with Cross-Compiler "ppc-linux-gcc (GCC) 3.2.2 20030217 (Yellow Dog Linux 3.0 3.2.2-2a_1)" and "GCC (Debian 4.4.5-8)" on my development system. > I expect a lot of the false positives will disappear when the includes problem > is fixed. Look at the screenshots! I can not see any wrong include in the project configuration (czUtilities_Properties.png). But I see all those wrong includes in the *.sc files (czUtilities-sc_Error.png). Created attachment 212863 [details]
*.sc file
The requested project settings file (*.sc)
Created attachment 212864 [details]
CODAN shows an error even with correct project settings
Created attachment 212865 [details]
project properties
Created attachment 212866 [details]
detected error inside the sc file
Created attachment 212870 [details]
Project Explorer View shows incorrect includes
(In reply to comment #26) > > I expect a lot of the false positives will disappear when the includes problem > > is fixed. > Look at the screenshots! Thanks for those. > configuration (czUtilities_Properties.png). But I see all those wrong includes > in the *.sc files (czUtilities-sc_Error.png). Ok, that must be where the ambiguity comes from. It looks like scanner discovery didn't run correctly, probably because of bug 353786. Try this: - For all your projects, including libraries: Project properties, C/C++ General, Discovery options, make sure that the Compiler invocation command is ppc-linux-gcc and ppc-linux-g++ for C and C++ languages respectively. - Exit Eclipse, delete your .sc files, start Eclipse - Build - Check the .sc files, they should contain the /opt paths now if it worked correctly - Reindex Hope this helps! (In reply to comment #29) > Created attachment 212865 [details] > project properties In that screenshot, I see you have -I/opt/eldk/ppc_82xx/usr/include. That should not be necessary once the .sc files contain the correct includes. I have committed to master (8.1) changes that should make creating cross compile projects less error prone, see bug 353890 comment 11. I think it's also worth mentioning that it's possible to an external plug-in might be modifying the built-in includes, such as the LLVM toolchain, see bug 376086 comment 10 . Nearly the same behavior is shown by Eclipse Juno. But if I open the source file with the CODAN error the message of the problem and the problem itself are vanishing. Maybe CODAN does miss a second or third pass which is done on opening the affected file. The last issue that I know of has been fixed (bug 369888). Now that the Cross GCC toolchain is using a language setting provider (bug 392404), this should work much better. (In reply to AK from comment #34) > Nearly the same behavior is shown by Eclipse Juno. But if I open the source > file with the CODAN error the message of the problem and the problem itself > are vanishing. Maybe CODAN does miss a second or third pass which is done on > opening the affected file. Some CODAN "checkers" only run when the file is opened so it's possible that you had the error first when includes where wrong and now they are vanishing as you open the files with the proper includes configured. If anyone wants to test the new version, it will be available in a few hours in the nightly build. Use update site: http://download.eclipse.org/tools/cdt/builds/luna/nightly |