Re: [cdt-dev] CDT GNU Error Parser: Places marker on wrong file

["Alain Magloire" <alain@xxxxxxx>]

> Eclipse: 2.1.x
> CDT: 1.2.0
> Windows XP
> Java 1.4.2_x
> 
> We have run into an issue with the GNU error parser in the CDT.  Using a
> Standard Make project, and exectuing a makefile we get the following error
> output (not the issue at hand):
> 
> Object_Lynx_Os/XXX-SS/Threading/lang_c/vmos/src/RC_FSSL_Thread.o: In
> function `RC_FSSL_Thread_create':
> RC_FSSL_Thread.c(200): undefined reference to `pthread_attr_init'
> RC_FSSL_Thread.c(201): undefined reference to `pthread_attr_setdetachstate'
> RC_FSSL_Thread.c(202): undefined reference to `pthread_attr_setstacksize'
> RC_FSSL_Thread.c(204): undefined reference to `pthread_attr_getschedparam'
> RC_FSSL_Thread.c(207): undefined reference to `pthread_attr_setschedparam'
> RC_FSSL_Thread.c(210): undefined reference to `pthread_create'
> RC_FSSL_Thread.c(230): undefined reference to `pthread_attr_destroy'
> 
> Now, given this error output we can see there is a problem with the file
> "RC_FSSL_Thread.c".  BUT, the catch is that there are two files with that
> name in the project:
> 
> ../../XXX-SS/Threading/lang_c/vmos/src/RC_FSSL_Thread.c
> ../../XXX-SS/Threading/lang_c/win/src/RC_FSSL_Thread.c
> 
> Unfortunately, the error parser decides to put the markers on the file in
> the "win" directory tree instead of the actual file used in the build (in
> the "vmos" tree).
> 
> I think I understand why it does this... after all, considering the parser
> can only come up with a file name, how is it suppose to guess correctly
> which file was actually used in the build or link?
> 

We are using some tricks with GNU make to do a better guess 
for example the GNU Make ErrorParser part of the error parser
should have detected the:
	make: Entering xxx directory
	make: Leaving ...
and indicate to the other error parsers the correct working directory.
So unless the makefiles are doing things really weird, we should be able
to do a better guess, before the raw search.

Could you make a PR with the output log, to track this one down.

> Could someone please confirm this is what is happening?  Any suggestion
> short of removing the duplicate file?
> 
> Right now I can see two courses of action:
> 
> 1) Place markers on both files, even though line#200 in the "win" file will
> not have any errors on it.  The engineer can figure it out.
> 2) Place markers on neither files and state in the task-list error marker
> that multiple files were found.
>