This is the mail archive of the
mailing list for the binutils project.
Re: ld using .. in search paths
On 09/06/11 15:34, Ian Lance Taylor wrote:
Bryan Ischo<firstname.lastname@example.org> 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.
No, the linker should do as it is told, no more, no less.
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?
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