Home » Language IDEs » C / C++ IDE (CDT) » CDT CODAN Indigo Could not resolve common symbols all of a sudden(CDT CODAN Indigo Could not resolve common symbols all of a sudden)
| CDT CODAN Indigo Could not resolve common symbols all of a sudden [message #891749] |
Mon, 25 June 2012 18:34  |
 Brian Bandy
Messages: 4
Registered: June 2012 |
Junior Member |
|
|
Hi,
As many others also appear to be having issues with CODAN in Indigo, I apologize for creating a new topic, but I've been reading those other topics and other blog posts, and have tried most (if not all) suggested solutions to no avail. So, I thought I would take a shot at providing some additional detail in the hope that it helps to reproduce, and narrow the cause of, these CODAN/CDT issues.
Here's a brief description of my environment:
I'm currently using Eclipse Indigo for C/C++ SR2.
I downloaded direct from the Eclipse site (3 weeks ago?) and installed to my /usr/local/ path.
My OS is Ubuntu 12.04, all updates current.
My kernel: Linux bbandy-laptop 3.2.0-25-generic #40-Ubuntu SMP Wed May 23 20:30:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
The gcc compiler installed with Ubuntu 12.04 is v4.6.3.
(I did have g++ 4.6 installed initially, but later uninstalled it after installing 4.7.)
I installed gcc/g++ 4.7.0 installed as follows:
$ sudo add-apt-repository ppa:ubuntu-toolchain-r/test
$ sudo apt-get install gcc-4.7 g++-4.7
$ sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.6 60 --slave /usr/bin/g++ g++ /usr/bin/g++-4.6
$ sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.7 40 --slave /usr/bin/g++ g++ /usr/bin/g++-4.7
$ sudo update-alternatives --config gcc
There are 2 choices for the alternative gcc (providing /usr/bin/gcc).
Selection Path Priority Status
------------------------------------------------------------
* 0 /usr/bin/gcc-4.6 60 auto mode
1 /usr/bin/gcc-4.6 60 manual mode
2 /usr/bin/gcc-4.7 40 manual mode
Press enter to keep the current choice[*], or type selection number: 2
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.7.0-7ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --disable-bootstrap --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.0 (Ubuntu/Linaro 4.7.0-7ubuntu3)
I've attached screenshots of my settings, and here's a screenshot showing the CODAN false hits.
I currently only have 1 project in my workspace.
This project contains only a single class ("Properties") as a test (also attached).
I *am* using the -std=c++11 compiler option and employing some C++11 language features.
I *am not* getting any CODAN false hits on C++11 language features, only std:: namespace (STL).
Eclipse *did* auto-discover all g++-4.7 paths appropriately (to the best of my knowledge).
The compile (with -Wall -Wextra -Wconversion warnings enabled) is warning- and error-free with both Make and Internal builders.
My project directory structure is: $HOME/workspace/bfcl/src/core/Properties.* (bfcl/src is the only source path in the project).
I'm not sure if this is a bug (yet), so I'm filing it as a Forum Topic. I would appreciate it if anyone else can reproduce this issue to confirm, or preferably, help me to resolve it via configuration settings.
My plan is to use the Eclipse IDE, and CODAN is a vital part of that plan. The feature can improve my productivity by reducing the number of compile cycles I require. Unfortunately, if CODAN isn't working, I'll have to attempt to disable it or the false hits can actually reduce my productivity since I'll probably chase a few of those rabbits down their holes unnecessarily.
If there's any additional information I can provide, please let me know.
Thank you!
- Brian
|
|
|
| Re: CDT CODAN Indigo Could not resolve common symbols all of a sudden [message #891796 is a reply to message #891749] |
Tue, 26 June 2012 03:22  |
Brian Bandy
Messages: 4
Registered: June 2012 |
Junior Member |
|
|
Here are the .log entries generated when I rebuild the CODAN index in CDT.
!SESSION 2012-06-25 22:13:47.803 -----------------------------------------------
eclipse.buildId=M20120208-0800
java.version=1.6.0_24
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US
Framework arguments: -product org.eclipse.epp.package.cpp.product
Command-line arguments: -os linux -ws gtk -arch x86_64 -product org.eclipse.epp.package.cpp.product
!ENTRY org.eclipse.cdt.core 1 0 2012-06-25 22:15:48.119
!MESSAGE Indexed 'bfcl' (2 sources, 210 headers) in 19.94 sec: 23,420 declarations; 38,884 references; 0 unresolved inclusions; 1,509 syntax errors; 3,373 unresolved names (5.14%)
Also, "Search for Unresolved Includes" finds 0 matches.
|
|
| | |
| Re: CDT CODAN Indigo Could not resolve common symbols all of a sudden [message #892041 is a reply to message #892030] |
Wed, 27 June 2012 00:19 |
Brian Bandy
Messages: 4
Registered: June 2012 |
Junior Member |
|
|
I may have just noticed something interesting w.r.t. this issue. I was creating an entirely new file and not having any STL symbol issues at all. Then I wrote, saved, and compiled a line without properly including the necessary header. Of course, the index failed to identify the symbol (std::move in this case), as expected. So next I added #include <algorithm>, saved, and recompiled. From this point on, std::move is still "missing" from the index. Nothing appears to fix the issue, exactly as with my previous example from this message thread.
I'm not 100% sure if std::move was valid before the missed compile (I don't think it could have been, as I didn't have the correct include, but I don't recall seeing a red squiggly under it).
I'll continue testing and update if I discover anything further.
Any thoughts???
- Brian
|
|
|
| Re: CDT CODAN Indigo Could not resolve common symbols all of a sudden [message #892058 is a reply to message #892041] |
Wed, 27 June 2012 02:46 |
David Wegener
Messages: 1445
Registered: July 2009 |
Senior Member |
|
|
On 06/26/2012 07:19 PM, Brian Bandy wrote:
> I may have just noticed something interesting w.r.t. this issue. I was
> creating an entirely new file and not having any STL symbol issues at
> all. Then I wrote, saved, and compiled a line without properly
> including the necessary header. Of course, the index failed to identify
> the symbol (std::move in this case), as expected. So next I added
> #include <algorithm>, saved, and recompiled. From this point on,
> std::move is still "missing" from the index. Nothing appears to fix the
> issue, exactly as with my previous example from this message thread.
>
> I'm not 100% sure if std::move was valid before the missed compile (I
> don't think it could have been, as I didn't have the correct include,
> but I don't recall seeing a red squiggly under it).
>
> I'll continue testing and update if I discover anything further.
>
> Any thoughts???
>
> - Brian
>
In your original post, you indicated that you are using -std=c++0x. The
discovery process may not be picking up on this setting which could
effect indexing. You might want to try adding the -std=c++0x argument
to the c++ Compiler invocation arguments on the Discovery Options page.
This will cause the the Discovery process to output the defines that
the argument causes g++ to set.
You may need to perform an Index rebuild after making the change.
The Index menu can be invoked from different points in your project
hierarchy. Make sure that you rebuild from the Project level and not
from a file in your project.
|
|
|
Goto Forum:
Current Time: Fri Apr 19 06:44:49 GMT 2024
Powered by FUDForum. Page generated in 0.01876 seconds |
] 
Search
Help
Register
Login
Home
