Community
Participate
Working Groups
If a path can't be resolved, the emitted link line has -L"". The result is that the linker eats the subsequent argument e.g.: Building target: mainProj Invoking: GCC C Linker gcc -L"/projects/firepath/apps/work/jamesb/runtime-New_configuration/libProj/Debug" -L"" -o"mainProj" ./src/mainProj.o Interestingly include paths which can't be resolved are excluded from the generated build line automatically (and there's a path entry warning). We shouldn't emit such empty link search paths as it ends up breaking the link in non-obvious ways.
Created attachment 169098 [details] proposed fix The handling of getToolCommandFlags treated include paths differently to all the other path/string list the difference being: path.length() > 0 && _!path.equals(EMPTY_QUOTED_STRING)_ If we return an empty string for _any_ of of the tool commands, we'll end up in a situation where the tool eats the following option: bug 163650 There seems to be no good reason to handle include paths differently to all the other string lists. Though the question remains, should we be checking for empty "" strings inother CdtVariableResolver resolved strings?
Committed
I did not look at the code but I assume logic is - for include user cannot specify empty string because it will make next argument an include i.e. gcc -I"" qq.c gcc: no input files But with macro it is normal gcc -DMACRO="" qq.c I am not sure how it is organized in there though -D"" would be bad too.
(In reply to comment #3) > I did not look at the code but I assume logic is - for include > user cannot specify empty string because it will make next argument an include > i.e. gcc -I"" qq.c > gcc: no input files > > But with macro it is normal > gcc -DMACRO="" qq.c Yes, that's right. When the command gets runs the argument array doesn't have the empty argument, so the following argument is incorrectly used. > I am not sure how it is organized in there though -D"" would be bad too. Yes, I think you're right. This problem only occurs when environment variables are expanded to "" though - which tends to only occur with workspace relative paths. So it's much less likely to happen for the defines.
*** cdt cvs genie on behalf of jblackburn *** Bug 313503 Shouldn't pass empty "" arguments to tool options as it results in subsequent arguments being eaten [*] Tool.java 1.97 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.managedbuilder.core/src/org/eclipse/cdt/managedbuilder/internal/core/Tool.java?root=Tools_Project&r1=1.96&r2=1.97
