This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ld using .. in search paths

On 09/06/11 15:34, Ian Lance Taylor wrote:
Bryan Ischo<> 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,

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]