Community
Participate
Working Groups
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.
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.
