dir/../ collapsing improvements (and bug fix?)

[Alexandre Oliva]

On Dec  2, 2005, DJ Delorie <dj@redhat.com> wrote:

> Note that libiberty has a canonicalize-path function too.

But this is not about canonicalizing pathnames.  This is about turning
broken pathnames into funcional ones.  Consider
/usr/bin/../lib/gcc/<target>/<version>/../../.., for example, when the
GCC version you're building with --prefix=/usr is not installed yet.
/usr/lib/gcc/<target>/<version> will not exist, but it is this very
sort of dot-dot pathnames that GCC will use to go from its version
directory to the location where it can find its headers and libraries.

The situation gets even more interesting in the AFS case, when
/usr/lib/../lib64 is not equivalent to /usr/lib64, and still, we want
GCC to use the latter if /usr/lib/../lib64 does not exist, because
/usr/lib is a link to somewhere that does not have a lib64 sibling, or
so I'm told.

> Note also that the main reason we don't always collapse .. is for
> cases like symlink/.. where symlink points elsewhere; collapsing that
> to . results in a different destination.

This is *exactly* the problem I'm trying to solve.  The idea is to
collapse dir/../ only when leaving it alone doesn't find the file
we're looking for, but removing it does.

So, no, canonicalization is not the answer, and certainly
unconditional collapsing isn't either.  I'm trying to leave pathnames
alone if there's no way to make them work, so that the error message
is not confusing, but to collapse dir/../ in a few situations we
didn't collapse them before, but only if not collapsing them wouldn't
have worked in the first place.

Or so I hope :-)

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}