Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 313503

Summary:

Empty linker search path if location can't be resolved

Product:

[Tools] CDT

Reporter:

James Blackburn <jamesblackburn+eclipse>

Component:

cdt-build-managed

Assignee:

James Blackburn <jamesblackburn+eclipse>

Status:

RESOLVED FIXED

QA Contact:

Chris Recoskie <recoskie>

Severity:

normal

Priority:

CC:

elaskavaia.cdt

Version:

7.0

Target Milestone:

7.0

Hardware:

OS:

Linux-GTK

Whiteboard:

Attachments:

Description	Flags
proposed fix	jamesblackburn+eclipse: iplog-

Description James Blackburn

2010-05-19 07:20:47 EDT

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.

Comment 1 James Blackburn

2010-05-19 08:20:04 EDT

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?

Comment 2 James Blackburn

2010-05-19 08:27:56 EDT

Committed

Comment 3 Elena Laskavaia

2010-05-19 10:33:42 EDT

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.

Comment 4 James Blackburn

2010-05-19 10:44:47 EDT

(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.

Comment 5 CDT Genie

2010-07-28 15:28:27 EDT

*** cdt cvs genie on behalf of jblackburn ***
Bug 313503 Shouldn't pass empty &quot;&quot; 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