Re: ld using .. in search paths

[Bryan Ischo <bryan at ischo dot com>]

On 09/06/11 15:34, Ian Lance Taylor wrote:
> Bryan Ischo<bryan@ischo.com>  writes:
>
> > Thank you for your response.  I am not sure exactly what the source of
> > the /../ paths was, I had assumed that it was a built-in search path
> > in ld, but maybe it was gcc passing -L arguments and it's gcc's doing.
> Yes, gcc routinely passes -L arguments with "/../".  Use gcc's -v option
> to see precisely how it invokes the linker.
>
>
> > In any case, would it be sensible for the program generating the
> > search paths to look in both the collapsed and un-collapsed forms of
> > the path, to cover both bases?
> No, the linker should do as it is told, no more, no less.

Thank you for your response.  I agree with your statement that the 
linker should do only what it was asked; but I am talking about the 
program generating the search paths, which apparently is gcc in this 
case.  I know that gcc's behavior is not necessarily a topic of 
discussion for the binutils list, but I am just wondering if it makes 
sense for gcc to do what I have proposed.  ld is being asked to search 
some paths and apparently gcc believes that the way that these paths can 
be specified can include "phantom" paths that do not exist (i.e. 
foo/bar/../baz where foo/bar does not exist but foo/baz does) but ld 
does not accept these paths as being meaningful in the way that gcc 
intended.  I think that the fault lies with gcc believing that it can 
compose paths piecemeal and use /../ as a way to fold paths when in fact 
this is not technically valid.  I just want to confirm that it is not 
valid to pass a path in which not every component exists and expect that 
/../ should still work, from the point of view of binutils.  If so, I 
will take this up with the gcc authors.

So to summarize, is the following true:

1. binutils accepts search paths as strings to pass directly to the 
operating system file functions and will not manipulate them in any way 
before doing so
2. paths that include embedded /../ are not valid if any component of 
the path does not exist
3. therefore, any program which expects to reference existing files via 
paths that include /../ and for which some path components do not exist, 
is in error
4. gcc passes such paths to ld and thus gcc is in error in doing so and 
should be fixed
5. the urgency of this fix to gcc is low since very rarely do the 
standard system search paths in question not exist on a platform

Thank you,
Bryan