Home Original page

ld using .. in search paths

Bryan Ischo bryan@ischo.com
Wed Aug 31 20:14:00 GMT 2011 
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
More information about the Binutils mailing list