Bugzilla – Full Text Bug Listing
| Summary: | CDT Indexer can't find constants from limits.h on Linux | ||
|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Colin Simmonds <colin.simmonds> |
| Component: | cdt-indexer | Assignee: | Project Inbox <cdt-indexer-inbox> |
| Status: | RESOLVED INVALID | QA Contact: | Markus Schorn <mschorn.eclipse> |
| Severity: | normal | ||
| Priority: | P3 | CC: | cdtdoug, malaperle, rion4ik, tekin, yevshif |
| Version: | 8.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Attachments: | |||
The include_next feature is supported by CDT. Chances are that the include search path is not setup correctly. Please construct a self-contained example that shows the problem. Created attachment 193745 [details]
Screenshot showing the indexer error on the source code
Created attachment 193746 [details]
Screenshot showing that the sample code compiles without errors
Created attachment 193747 [details]
Screenshot showing the output when sample program is run
Created attachment 193748 [details]
Screenshot showing the include path for the project
The sample program I provided in the initial bug report demonstrates the problem. In the GUI, the indexer reports "Symbol 'PATH_MAX' could not be resolved.", but at compile time the symbol is correctly found and its value outputted correctly at runtime, as shown in the attached screenshots. I also took a screenshot to show the C include path, which is the default here with no changes. The problem you are experiencing depends on the environment you are working in. I am working on windows using cygwin or mingw and with that I cannot reproduce the problem. --> It be great if you can create a self-contained example, e.g. by copying the necessary system headers into a project, or by constructing a similar problem with some self written header files. Created attachment 200332 [details]
self-contained example
I'm experiencing the same problem.
Unfortunatelly I don't know how to create proper self-contained example,
but anyway I made one..
I copied headers limits.h and syslimits.h from gcc 4.5.2.
include_next is unchanged.
btw adding #include <linux/limits.h> fixes indexer Thanks, I can reproduce the issue: Include next fails when file-name does not match included file-name. Actually our implementation of include-next conforms with the gnu preprocessor. Looking at an installtion of gcc on linux I see that it uses 5 include directories. In my case these are: /usr/local/include /usr/lib64/gcc/x86_64-suse-linux/4.3/include /usr/lib64/gcc/x86_64-suse-linux/4.3/include-fixed /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/include /usr/include I guess that your include search path is not complete. What does gcc output when you invoke it with 'gcc -E -P -v test.c', where test.c is an empty file? $ LANG=C gcc -E -P -v test.c Using built-in specs. COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.5.3/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.5.3/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.5.3-r1/work/gcc-4.5.3/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.5.3 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.5.3 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.5.3/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.5.3/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --with-ppl --with-cloog --disable-ppl-version-check --with-cloog-include=/usr/include/cloog-ppl --disable-lto --enable-nls --without-included-gettext --with-system-zlib --disable-werror --enable-secureplt --enable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --enable-cld --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.5.3/python --enable-checking=release --disable-libgcj --enable-languages=c,c++,objc,obj-c++ --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.5.3-r1 p1.0, pie-0.4.5' Thread model: posix gcc version 4.5.3 (Gentoo 4.5.3-r1 p1.0, pie-0.4.5) COLLECT_GCC_OPTIONS='-E' '-P' '-v' '-mtune=generic' '-march=x86-64' /usr/libexec/gcc/x86_64-pc-linux-gnu/4.5.3/cc1 -E -quiet -v -P test.c -D_FORTIFY_SOURCE=2 -mtune=generic -march=x86-64 ignoring nonexistent directory "/usr/local/include" ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../x86_64-pc-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/include /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/include-fixed /usr/include End of search list. COMPILER_PATH=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.5.3/:/usr/libexec/gcc/x86_64-pc-linux-gnu/4.5.3/:/usr/libexec/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../x86_64-pc-linux-gnu/bin/ LIBRARY_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../x86_64-pc-linux-gnu/lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-E' '-P' '-v' '-mtune=generic' '-march=x86-64' (In reply to comment #12) Correcting the include search path to (see gcc's output) /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/include /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/include-fixed /usr/include should fix your issue. I'll wait for fix in CDT since gcc itself works perfect as well as cdt-7.0.2 which I use atm =) (In reply to comment #14) > I'll wait for fix in CDT since gcc itself works perfect as well as cdt-7.0.2 > which I use atm =) I don't know what to fix, though. anyway cdt-8 from my point of view is slightly more unstable than 7.0.2, especially autotools integration. and moreover I don't know how to change search path globally w/o patching and recompiling gcc. and proposed fix, as I understand, just removes not existing directories what doesn't look right. so maybe you will have some ideas later. I'll wait. To me it looks like there is a difference between the include search path the compiler is using (as reported by 'gcc -E -P -v test.c') and the include search path that is passed to the parser. Is this the case? No response from submitter. (In reply to comment #13) > (In reply to comment #12) > Correcting the include search path to (see gcc's output) > /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/include > /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/include-fixed > /usr/include > should fix your issue. no, it doesn't fix the issue. see attached screenshot Created attachment 205406 [details]
include patch screenshot
still broken with latest eclipse-4 just a small investigation based on my assumptions of inclusion order... search paths: /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1/include /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1/include-fixed /usr/include first limits.h is in /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1/include-fixed and it doesn't have PATH_MAX but has #include_next <limits.h> which is included from /usr/include second limits.h has next code: #ifdef __USE_POSIX /* POSIX adds things to <limits.h>. */ # include <bits/posix1_lim.h> #endif /usr/include/bits/posix1_lim.h unconditionally includes #include <bits/local_lim.h> /usr/include/bits/local_lim.h also unconditionally includes #include <linux/limits.h> which finally has PATH_MAX defined. I tried to add CFLAGS with -D__USE_POSIX to my autotools project but w/o success. So I just hope you guys will fix this annoyed bug one day. as far as I understand /usr/include/limits.h is not parsed at all by eclipse since even _LIBC_LIMITS_H_ is marked as undefined in the editor. but in project explorer in "Includes" I can see /usr/include. so something is really wrong with cdt. this bug should be reopened. Same bug continues, limits.h can be found under usr/include and is listed in the project tree however Eclipse still complains that the preprocessor definitions do not exist. |
Build Identifier: I20110310-1119 The following program compiles and runs fine on Eclipse, but the Indexer flags PATH_MAX as a symbol that could not be resolved. #include <stdio.h> #include <stdlib.h> #include <limits.h> int main(void) { printf("PATH_MAX is %d\n", PATH_MAX); return EXIT_SUCCESS; } On Linux, glibc's limits.h uses recursion via #include_next <limits.h> before finding the definition of this and related constants from /usr/include/linux/limits.h, which presumably is why the indexer has a problem with it. Reproducible: Always Steps to Reproduce: 1. Create a new C project using the above source code. 2. Let the indexer run. See that PATH_MAX is flagged with an error marker. 3. Build the project, which should succeed, but the error marker is not removed from the source file.