Community
Participate
Working Groups
Pressing enter at the end of the Summary field on new bug entry submits the new bug. Duh. Anyway, the output from our Makefile says for each C source file built: CCACHE_DIR=/tmp/ccache CCACHE_UMASK=002 /localhome/buildtools/linux_ia32_sdk_2004_06/bin/ccache /localhome/buildtools/linux_ia32_sdk_2004_06/bin/gcc -MMD -Wall -Wno-unused -Wno-unknown-pragmas -march=pentiumpro -Winline -DUSE_GCC_STATIC_INLINE -DTIMING_INLINE_DISABLED -g -DSIGNALIO -DJR_POSIX -DJR_LINUX -DX86 -D_IA32 -DIA32 -DADDRESS32 -D_CONSOLE -D_MBCS -D_GNU_SOURCE -D__BOOT_KERNEL_SMP=1 -D_DEBUG -DDEBUG -nostdinc -isystem /localhome/buildtools/lib_linux_ia32_2004_05/include -isystem /localhome/buildtools/linux_ia32_sdk_2004_06/include -isystem /localhome/buildtools/linux_ia32_sdk_2004_06/include/linux -isystem /localhome/buildtools/linux_ia32_sdk_2004_06/usr/include -isystem /localhome/buildtools/linux_ia32_sdk_2004_06/usr/include/linux -iwithprefixbefore include -I../../../../src/jvm -I. -I../../../../src/ext -I../../../../src/jvm/native/jni -I.. -c ../../../../src/jvm/code/codegen.c -o code/codegen.o I don't know what Bugzilla does to the above, but it's supposed to be all on one line. The discovered paths are "/usr/local/include", "/usr/gcc-lib/i386-redhat-linux/2.96/include" and "/usr/include". We use none of those. A bunch of preprocessor symbols are discovered as well, including "__GNUC_MINOR__" which has the value from /usr/bin/gcc rather than /localhome/buildtools/linux_ia32_sdk_2004_06/bin/gcc. What I did was this: 1. Create a new C project, std make, make sure macro and scanner path discovery are enabled. 2. Import a legacy project. 3. Build. 4. Right-click the project in the Navigator view. 5. "Properties" 6. "C/C++ Include Paths and Symbols" I realize the above case isn't the most obvious one, but it would be great if you could support it! ccache btw is an excellent spinoff from the Samba project, more info at "http://ccache.samba.org/".
Looks like missing handling of -isystem.
Actually, part of the problem is the default "gcc" assumed by Path Discovery. The one you want isn't the one on your path. Johan, please change the following: 1. Correct where discoveries come from. From Project > Properties > Make Project > Discovery Options: disable "Use default", then replace "gcc" with "/localhome/buildtools/linux_ia32_sdk_2004_06/bin/gcc" on the Scanner Config Info Command. 2. Remove the old discoveries. From Project > Properties > Include Paths & Symbols Expand project, select "Discovered Paths", Edit... Delete the Includes icon and the Symbols icon. 3. Build your project. This should "discover" the paths that are built into the compiler. Your -nostdinc and -isystem flags are going to override this. If this is what you want to do "permanently", then you can add your -nostdinc and -isystem flags to the Scanner Config Info Command in step 1. After a rebuild, the non-default paths are discovered.
I tried what you suggested. After some iterations (we don't have an "all" target so I had to change "all" to "debug" in the re-build command) this is what I did (using the same numbering you did): 1. I set the scanner config info command to "/localhome/buildtools/linux_ia32_sdk_2004_06/bin/gcc -nostdinc -isystem /localhome/buildtools/lib_linux_ia32_2004_05/include -isystem /localhome/buildtools/linux_ia32_sdk_2004_06/include -isystem /localhome/buildtools/linux_ia32_sdk_2004_06/include/linux -isystem /localhome/buildtools/linux_ia32_sdk_2004_06/usr/include -isystem /localhome/buildtools/linux_ia32_sdk_2004_06/usr/include/linux -iwithprefixbefore include -E -P -v ${plugin_state_location}/${specs_file}". 2. I removed the old discoveries. 3. Project -> Clean... -> Only the relevant project. My project is re-built, and Make outputs the line described above for each C source file built. Now, the discovery doesn't discover anything at all :-(. No preprocessor macros, and no #include paths. Are you sure your make output parser even recognizes the output from my Makefile as a compiler invocation? I could very well imagine either our ccache call or our environment variable assignments at the start of the line fooling your parser.
Johan, you're right there are at least two bugs here: 1) a Makefile line using shell variables fails to participate in Build Output Discovery: VAR=whatever g++ -I/home/bnicolle Foo.cpp 2) something about your/my Scanner Info Build line fails to result in a proper "Compiler-Intrinsic" Discovery. In my case the following command: /medusa/disk8/compilers/gnu/H-linux-i386-elf-2.95.3/bin/i386-elf-gcc -nostdinc - isystem /medusa/disk8/compilers/gnu/H-linux-i386-elf-2.95.3/lib/gcc-lib/i386- elf/2.95.3/include -isystem /medusa/disk8/compilers/gnu/H-linux-i386-elf- 2.95.3/i386-elf/include -isystem /medusa/disk8/compilers/gnu/H-i386-elf- 2.95.3/i386-elf/include -isystem /medusa/disk8/compilers/gnu/H-i386-elf- 2.95.3/lib/gcc-lib/i386-elf/2.95.3/include -isystem /home/bnicolle/include - iwithprefixbefore include -E -P -v {stuff} ...yields only a single Discovered Include... /medusa/disk8/compilers/gnu/H-linux-i386-elf-2.95.3/lib/gcc-lib/i386- elf/2.95.3/include ...despite producing apparently correct parseable stuff from the compiler: /medusa/disk8/compilers/gnu/H-linux-i386-elf-2.95.3/bin/i386-elf-gcc -nostdinc - isystem /medusa/disk8/compilers/gnu/H-linux-i386-elf-2.95.3/lib/gcc-lib/i386- elf/2.95.3/include -isystem /medusa/disk8/compilers/gnu/H-linux-i386-elf- 2.95.3/i386-elf/include -isystem /medusa/disk8/compilers/gnu/H-i386-elf- 2.95.3/i386-elf/include -isystem /medusa/disk8/compilers/gnu/H-i386-elf- 2.95.3/lib/gcc-lib/i386-elf/2.95.3/include -isystem /home/bnicolle/include - iwithprefixbefore include -E -P -v test.c Reading specs from /medusa/disk8/compilers/gnu/H-linux-i386-elf-2.95.3/lib/gcc- lib/i386-elf/2.95.3/specs gcc version 2.95.3 20010315 (release) /medusa/disk8/compilers/gnu/H-linux-i386-elf-2.95.3/lib/gcc-lib/i386- elf/2.95.3/cpp0 -lang-c -nostdinc -v -P -D__GNUC__=2 -D__GNUC_MINOR__=95 - D__i386__ -D__i386__ -Acpu(i386) -Amachine(i386) -Acpu(i386) -Amachine(i386) - Di386 -D__i386 -D__i386__ -isystem /medusa/disk8/compilers/gnu/H-linux-i386-elf- 2.95.3/lib/gcc-lib/i386-elf/2.95.3/include - isystem /medusa/disk8/compilers/gnu/H-linux-i386-elf-2.95.3/i386-elf/include - isystem /medusa/disk8/compilers/gnu/H-i386-elf-2.95.3/i386-elf/include - isystem /medusa/disk8/compilers/gnu/H-i386-elf-2.95.3/lib/gcc-lib/i386- elf/2.95.3/include -isystem /home/bnicolle/include -iwithprefixbefore include test.c GNU CPP version 2.95.3 20010315 (release) (i386 bare ELF target) #include "..." search starts here: #include <...> search starts here: /medusa/disk8/compilers/gnu/H-linux-i386-elf-2.95.3/lib/gcc-lib/i386- elf/2.95.3/include /medusa/disk8/compilers/gnu/H-linux-i386-elf-2.95.3/lib/gcc-lib/i386- elf/2.95.3/include /medusa/disk8/compilers/gnu/H-linux-i386-elf-2.95.3/i386-elf/include /medusa/disk8/compilers/gnu/H-i386-elf-2.95.3/i386-elf/include /medusa/disk8/compilers/gnu/H-i386-elf-2.95.3/lib/gcc-lib/i386- elf/2.95.3/include /home/bnicolle/include End of search list. The following default directories have been omitted from the search path: /medusa/disk8/compilers/gnu/H-linux-i386-elf-2.95.3/lib/gcc-lib/i386- elf/2.95.3/../../../../../include/g++-3 /medusa/disk8/compilers/gnu/H-linux-i386-elf-2.95.3/lib/gcc-lib/i386- elf/2.95.3/include /medusa/disk8/compilers/gnu/H-linux-i386-elf-2.95.3/lib/gcc-lib/i386- elf/2.95.3/../../../../i386-elf/sys-include /medusa/disk8/compilers/gnu/H-linux-i386-elf-2.95.3/lib/gcc-lib/i386- elf/2.95.3/../../../../i386-elf/include End of omitted list. Johan, I assume if you run... touch test.c /path/to/your/gcc {your args} -E -P -v test.c ... you end up with some kind of roughly similar output to me. Vlad, feel free to use my command-line above for testing locally.
PR was not targeted to any particular release. Changing target milestone to 2.1
Ok, the problem is extra space characters between options. Depending on positions of extra space characters Discovery may capture some, none or all include paths. The patch has already been submitted (not committed yet). As a workaround, try removing extra space characters between the options.
By adding extra spaces, I mean for example the extra space between .../bin/gcc and -nostdinc. 1. I set the scanner config info command to "/localhome/buildtools/linux_ia32_sdk_2004_06/bin/gcc -nostdinc -isystem /localhome/buildtools/lib_linux_ia32_2004_05/include -isystem /localhome/buildtools/linux_ia32_sdk_2004_06/include -isystem /localhome/buildtools/linux_ia32_sdk_2004_06/include/linux -isystem /localhome/buildtools/linux_ia32_sdk_2004_06/usr/include -isystem /localhome/buildtools/linux_ia32_sdk_2004_06/usr/include/linux -iwithprefixbefore include -E -P -v ${plugin_state_location}/${specs_file}".
I'm mostly interested in having this fixed in some future release of Eclipse. A workaround isn't that important to me. As long as you can get include path and macro definition symbol discovery working for you with my example command line, that would be fine by me.
I agree and would like to see this fixed earlier rather than later. Vlad can you (also) submit the patch to the 2.0.x stream, and change this bug to Target Milestone 2.0.1?
Fixed both in 2.0.1 and in HEAD.
