This is the mail archive of the binutils@sourceware.org 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]

ld using .. in search paths


OK I know this is likely to be a completely irrelevant issue for most people but I recently experience a very puzzling problem that ended up to be due to ld's use of '..' in its search paths.

In brief, I had a situation where I did not have a $sysroot/usr/lib but I did have a $sysroot/usr/lib64. ld was being run with --sysroot=$sysroot, and none of the search path that it used when finding crti.o were able to find it. But in fact this path *would* have found if $sysroot/usr/lib existed:

$sysroot/usr/lib/../lib64/crti.o

While we can recognize that this path should be equivalent to:

$sysroot/usr/lib64/crti.o

In fact the Linux access() function fails when any of the directories listed in the path do not exist.

For example:

$ mkdir -p foo/bar
$ mkdir -p foo/baz
$ ls foo/cheebie/../baz
ls: cannot access foo/cheebie/../baz: No such file or directory
$ ls foo/bar/../baz
$

What I am wondering is why does ld use these paths with '..' in them if they are subject to this issue? Why not collapse the '..' out of its search paths before passing them to access? I realize like I said that it's unusual to be in a circumstance where this issue would cause the failure that I saw, but still, unless there is a good reason *not* to collapse all 'whatever/..' out of ld search paths, I don't see why not do so and avoid any potential problems.

I'd be happy to submit a patch for this if it's deemed worthwhile.

Thanks,
Bryan


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