libedit

[Corinna Vinschen]

On Apr  5 21:02, Peter Stuge wrote:
> J.A. Neitzel wrote:
> > Oh, I see...  This seems a strange problem since //usr/lib64/lib
> > is a valid UNIX pathname.
> 
> The problem isn't // but rather that configure always appends the lib
> directory, when in a multilib system lib64 is the final directory
> component in the path.

Whatever the exact problem is, I have to chime in here because, while
//usr/lib64/lib is a valid UNIX path, it's *NOT* necessarily the same as
/usr/lib64/lib, and the difference is quite important at least for Cygwin.

Here's the relevant snippet from POSIX-1.2008:

  4.12 Pathname Resolution

  [...]
  A pathname consisting of a single <slash> shall resolve to the root
  directory of the process. [...]
  A pathname that begins with two successive <slash> characters may be
  interpreted in an implementation-defined manner, although more than
  two leading <slash> characters shall be treated as a single <slash>
  character.

The identical definition was already part of POSIX-1.2001.  A path
starting with two leading slashes may be interpreted in an
implementation-defined manner.  That's the case for Cygwin, which
interprets these paths as an UNC path pointing to a shared directory of
a remote server:

  //server/share/...

according to the Win32 syntax for UNC paths.  Since that's backed by
POSIX, it would be nice if such paths are not lazily generated in
scripts or, even worse, in executables.

In the above case that means, Cygwin would try to access the directory
"lib" on a share "lib64" on the remote machine called "usr".  I hope
you can see how this is a bad idea.


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat