This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
ld using .. in search paths
- From: Bryan Ischo <bryan at ischo dot com>
- To: binutils at sourceware dot org
- Date: Wed, 31 Aug 2011 11:59:47 -0700
- Subject: 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