1

I'm having trouble with c++11 code in Eclipse CDT. The code compiles fine, but in the editor I see that all references to c++11 standard library (such as std::shared_ptr and std::chrono::milliseconds) are flagged as errors by the discovery service / indexer, which prevents the program from being run. The include files are found, but I think the proper flags and macros aren't getting propagated through to CDT's internal checks, so none of the types or main content of the headers are defined. I also can't seem to change the appropriate settings in the project properties.

I've browsed other posts describing similar issues and possible fixes, such as:

Some solutions mask the problem by disabling the indexer, or by disabling specific errors/warnings, but this is not desirable as I do want to see true errors when they occur.

Other (and probably more correct) solutions describe how to pass through appropriate macros (e.g,. __GXX_EXPERIMENTAL_CXX0X__) and build flags (e.g., -std=c++11), but here's what I think is the main issue: I can't change these settings in the IDE. In "Project -> Properties -> C/C++ General -> Preprocessor Include Paths, Macros, etc", the Entries and Providers tabs are grayed out / disabled. Similarly, in "Project -> Properties -> C/C++ Build -> Settings", there are no tabs for Tool Settings or Discovery as mentioned in some of the other posts.

Some particulars: I'm using Kepler build 20140224-0627 on Ubuntu 13.10 x64. The code I'm trying to work with is for Android NDK (latest version, r9d), and I have Google's NDK plugin installed. Compiler is gcc 4.8, and using gnustl_static runtime library. Perhaps using the NDK toolchain/plugin disables the settings that I need to modify?

Any help is greatly appreciated.

Community
  • 1
  • 1
drmatt
  • 13
  • 3
  • 1
    Made some progress - turns out that the macro `__cplusplus` should be forced to `201103L`, otherwise the content of the include files is ignored (everything is embedded inside a `#ifdef`). For some reason, `__GXX_EXPERIMENTAL_CXX0X__` is not recognized by the indexer despite being added to the Symbols. – drmatt Apr 05 '14 at 18:17

2 Answers2

4

First, make sure that your project compiles correctly.

After that, go to C/C++ Build->Tool Chain Editor and choose Current toolchain: Linux GCC (you may need to switch off Display compatible toolchains only). Make sure that the Current builder is still Android Builder.

Now you have full access to C/C++ General->Paths and Symbols page, with h Includes and # Symbols tabs.

On these two tabs, I add manually

C:/Android/android-ndk-r9d/sources/cxx-stl/gnu-libstdc++/4.6/include
C:/Android/android-ndk-r9d/sources/cxx-stl/gnu-libstdc++/4.6/libs/armeabi/include
C:/Android/android-ndk-r9d/sources/cxx-stl/gnu-libstdc++/4.6/include/backward

and 

__GXX_EXPERIMENTAL_CXX0X__ = 1

Maybe you need to switch to C/C++ Perspective, right-click on the project and launch Index->Rebuild.

Alex Cohn
  • 56,089
  • 9
  • 113
  • 307
  • I had access to the include paths already, without needing to change the toolchain settings, and the standard library paths were already set properly (otherwise I think the project wouldn't build?). Nonetheless, I tried your suggestion, and get the same result: project builds, but editor displays errors. – drmatt Mar 26 '14 at 00:19
  • I bet that you have build paths set up correctly. The problem is with the *Indexer* paths, which only effect editor. I am sorry this workaround didn't help you. Maybe you should add more subdirectories from `gnu-libstdc++`? My fix was only to recognize `std::shared_ptr`. And make sure you point to `gnu-libstdc++/4.8`! – Alex Cohn Mar 26 '14 at 06:23
  • Thanks, finally got back to this and tried your suggestion. Still does not work, unfortunately - even `std::shared_ptr` is not recognized. I think I need to somehow pass the `-std=c++11` flag to the indexer, but as mentioned in the original post, the Eclipse settings panes for this are grayed out or not present and I don't know how else to do it. Any other suggestions are appreciated! – drmatt Apr 05 '14 at 02:21
  • When you switch to **Linux GCC** toolchain, you can `#define` **__GXX_EXPERIMENTAL_CXX0X__** which for indexer is equivalent to `std=c++11` flag – Alex Cohn Apr 05 '14 at 10:29
  • Right, I did define that for all configurations / all languages along with setting the include paths - no luck, same result. Strange thing is, the editor is ok with the #includes (no errors there) and if I right click one of them (say, chrono) and open the file, it finds the right one in the ndk tree. So it's including the right file, but not defining any of the symbols in it, which suggests a macro definition or compiler flag that isn't getting passed through properly. – drmatt Apr 05 '14 at 18:10
  • You mean, it finds `` in `~/android-ndk-r9d/sources/cxx-stl/gnu-libstdc++/4.6/include`, right? – Alex Cohn Apr 05 '14 at 19:50
  • 1
    Yep, it finds `` in the proper ndk directory even when I use the Android toolchain (and also when following your suggestion to use the linux toolchain with manually added paths). I think the missing piece was defining `__cplusplus` to `201103L`, which the `-std=c++11` flag does implicitly. – drmatt Apr 06 '14 at 05:17
  • I didn't need to change the toolchain but your include directories were very helpful. – atablash Jun 25 '14 at 18:31
0

I have two contributions here:

  1. Update Eclipse if you can. They fix things now and then :)
  2. Generate a parser log file.

The first is self-explanatory, but I came to find out that my Eclipse config didn't have update sites configured, so I had to do that detour.

The second is hidden in plain site in the Project menu. The Indexing menu in Mars (Project / C-C++ Index) has "Create Parser Log File". This command generates a log pertaining to how it goes when the indexer parses the file that is "current" in the editor (i.e. the one you can see the red squigglies on at the moment). Generate that log and it will be opened automatically in an editor tab. If the indexer has a bug, it might report something interesting in this log. In my case it showed some headers such as <memory> were not parsed. That was certainly how it was acting, too. That was reported down at the bottom of the log, below all the info about what was successfully parsed. That enabled me to focus my investigation on a bug hunt rather than a configuration error or database corruption. Fortunately the bug that afflicted me was fixed in a newer version of Mars.

Mr Lister
  • 45,515
  • 15
  • 108
  • 150
cardiff space man
  • 1,442
  • 14
  • 31