Community
Participate
Working Groups
I had a working project under Eclipse Oxygen 1. I recently tried to upgrade to Eclipse Oxygen 2 (which, if I understand correctly, uses CDT 9.4). After installation, I found that essentially all of the references to standard library functions or classes in my code (e.g. to 'std::string') were marked as errors in Eclipse editor windows. When I looked in my "Project Properties -> C/C++ General -> Preprocessor Include Paths, Macros, Etc. -> Entries -> GNU C++ -> CDT GCC Built-in Compiler Settings Cygwin [Shared]" list, all of the paths that were listed there were listed in UNIX syntax, for instance "/usr/lib/gcc/i686-pc-cygwin/5.4.0/include/c++". I compared these paths with the corresponding paths on my previous Oxygen 1 Eclipse installation, and discovered that there, the same paths were listed using DOS/Windows paths (e.g. "C:\CygWin\lib\gcc\i686-pc-cygwin\5.4.0\include\c++"). It appears that this new version of Eclipse is somehow failing to translate the UNIX paths that were returned by the "provider discovery" process (which, if I understand correctly, runs "gcc.exe -x c++ -v -E" to ask gcc where its paths are) into their Windows equivalents. In my case, Eclipse is being invoked from within a command box under Windows (and not from within a bash shell or other Cygwin construct.) When Eclipse is invoked this way, it has no way to use the UNIX paths that it has been given by gcc, and therefore fails to find gcc's standard libraries. Apparently previous versions of Eclipse performed a translation from UNIX to Windows paths (probably using Cygwin's 'cygpath' executable provided for this purpose), and the current version of Eclipse, for some reason that I have not been able to discover, does not. I am currently unable to upgrade to the latest version of Eclipse due to this regression. Please make this work as it did before. Also, a workaround would be helpful. Thanks.
I am disappointed that nobody has apparently even commented on this bug yet. This seems like a pretty major regression in the latest version of Eclipse/CDT which makes it essentially unusable for people using CygWin GCC on Windows. I also discovered that updating to the latest version of CygWin seems to trigger a similar problem even on the Eclipse Oxygen 1 release, so simple "don't upgrade to Oxygen 2" wasn't sufficient to avoid the problem. After a lot of googling and experimentation, I was able to figure out an ugly workaround, as follows: First click on the project in the Project Explorer view, expand its contents, and verify that the items under the "Includes" node have paths naming Unix directories that don't actually exist on the Windows filesystem, and that they are grayed out (which means that Eclipse can't find them). Leave this node in the Project Explorer expanded so it is still visible. Then go to Window->Preferences->C/C++->Build->Settings, in the Discovery tab. (If there is no Discovery tab, then you might need to make it visible, via Window->Preferences-> C/C++ > Property Pages Settings). Then select "CDT GCC Built-in Compiler Settings Cygwin [Shared]", and, in the "Command to get compiler specs" text box, enter "cmd /c d:\scripts\fakegcc.cmd" rather than the usual text that appears there (which is, by default, something like '${COMMAND} ${FLAGS} -E -P -v -dD "${INPUTS}"'). Then create a fakegcc.cmd command in the directory mentioned in the text box (d:\scripts in the above example) which contains: @echo off @setlocal set INVOKE=g++ -E -P -v -dD D:/myworkspace/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.C -std=c++11 %INVOKE% 2>&1 | sed "s|/usr/|C:/cygwin/usr/|g; s|/usr/lib/|/lib/|g; s|/../include/w32api|/../usr/include/w32api|g;" where D:/myworkspace is the path to the workspace you are using, and C:/cygwin is the path to where CygWin is installed. Note that this assumes that 'sed' is installed and on the path, as part of the CygWin installation or otherwise. Then go to Window->Preferences->C/C++->Build->Settings, in the Discovery tab, and select "CDT GCC Built-in Compiler Settings Cygwin [Shared]", and click the "Clear Entries" tab. Hopefully, if all has gone well, this will cause the items under the "Includes" node to update to have path naming unix directories that now actually exist on the Windows filesystem and are therefore not grayed out. Now, right-click each project and select Index->Rebuild from the context menu. Once indexing is complete, the red marks for items like "std::string" should then disappear. This workaround is fairly painful, but it's the only thing I have found that worked. Please fix this bug!
See also bug #515618.
