Pathnames with two (or more) slashes in Makefile.c (was: Latest configure.in change breaks building)

[Sascha Wilde <wilde@sha-bang.de>]

Jan Djärv <jan.h.d@swipnet.se> wrote:
> Sascha Wilde skrev:

>> the latest change on configure.in:
>>
>> 2007-01-26  Jan Djärv  <jan.h.d@swipnet.se>
>>
>> * configure.in: Add check for libXft.
>>
>> breaks the build process for me (CVS Head on GNU/Linux with GTK+ frontend):
>>
>> The new configure tests are successful: checking for xft >=
>> 0.13.0... yes checking XFT_CFLAGS... -I/usr/X11R6/include
>> -I/usr/include/freetype2 checking XFT_LIBS... -L//lib
>> -L/usr/X11R6/lib -lXft -lXrender -lX11 -lXext
>> -lfontconfig -lfreetype -lz
>
> What is //lib?  It looks broken.

//lib == /lib, see below...

[...]
> You have -L -lncurses in there.  What happens is when the preprocessor
> reads Makefile.c (generated from Makefile.in), your -L//lib ... is
> taken as a comment, and everything after // is removed, so you are
> left with -L.

You are right, the problem is not in your patch, but was triggered by
it on m system.

fontconfig.pc (one of the dependencies of xft.pc) on my system looks
like this:

  prefix=/usr
  exec_prefix=/
  libdir=${exec_prefix}/lib
  includedir=${prefix}/include

  Name: Fontconfig
  Description: Font configuration and customization library
  Version: 2.3.2
  Libs: -L${libdir} -lfontconfig
  Cflags: -I${includedir}

So yes, the library include directory is set to "//lib", in fact this
is a very common idiom in various situations when the prefix
installation path of software is set to "/".

In fact, it isn't wrong at all (though it touches a certain corner
case of the posix definition just by chance), the last paragraph in
the section "Pathname Resolution" (chapter "General Concepts") from
the posix standard states:

  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.

On GNU Systems (and most unixoid systems I know), two leading slashes
are not interpreted in any special way, but like three and more
slashes: they are treated as one.

So the problem is, that the double slash is written unquoted to
Makefile.c where it gets interpreted as a comment.

This is IMO a bug.

When generating Makefile.c consecutive slashes hould either be reduced
to one or appropriately quoted.

cheers
sascha
-- 
Sascha Wilde
Nothing is fool-proof to a sufficiently talented fool.