Re: pari compilation problems after cygwin updates

[Bill Allombert <allomber@math.u-bordeaux.fr>]

On Fri, Jul 01, 2005 at 02:44:39PM -0400, David Mosher wrote:
> Fri 2005-07-01 00:59:00 +0200, Bill Allombert wrote:
> 
> >It is traditional on UNIX to handle //include as an alias for /include.
> 
> Here is the final paragraph of §4.11 "Pathname Resolution" of the "Single 
> UNIX Specification, Version 3" (ISO/IEC 9945:2003 [ISO POSIX (2003)]; IEEE 
> Std 1003.1, 2004 Edition; The Open Group Base Specifications, Issue 6), 
> <http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_11>:
> 
>   A pathname consisting of a single slash shall resolve to the root
>   directory of the process. A null pathname shall not be successfully
>   resolved. A pathname that begins with two successive slashes may be
>   interpreted in an implementation-defined manner, although more than two
>   leading slashes shall be treated as a single slash.

> My vague recollection is that there's nothing new here, and that an 

Oh, sure // is iirc a plan 9 legacy. This is the origin of the double / in
http://host/page and of SMB \\host\share notation. emacs also support it
for transparent ftp.

> initial double-slash has been a "special case" in POSIX for quite some time.

Sure, but allowed by POSIX does not make it 'traditional'. The problem
is that configure-like scripts and Makefile in general tend to generate
path with embedded //, due to the use of standard contructs like
${prefix}/include. They are all buggy as soon as //include is not an
alias for /include, the users being within their right to set prefix to
'/'. Fixing that is painful.

Cheers,
Bill.