[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Pathnames with two (or more) slashes in Makefile.c (was: Latest configur
From: |
Sascha Wilde |
Subject: |
Pathnames with two (or more) slashes in Makefile.c (was: Latest configure.in change breaks building) |
Date: |
Sun, 28 Jan 2007 15:28:11 +0100 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.0.93 (gnu/linux) |
Jan Djärv <address@hidden> wrote:
> Sascha Wilde skrev:
>> the latest change on configure.in:
>>
>> 2007-01-26 Jan Djärv <address@hidden>
>>
>> * 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.
- Latest configure.in change breaks building, Sascha Wilde, 2007/01/27
- Re: Latest configure.in change breaks building, Jan Djärv, 2007/01/28
- Pathnames with two (or more) slashes in Makefile.c (was: Latest configure.in change breaks building),
Sascha Wilde <=
- Re: Pathnames with two (or more) slashes in Makefile.c, Jan Djärv, 2007/01/29
- Re: Pathnames with two (or more) slashes in Makefile.c, Sascha Wilde, 2007/01/29
- Re: Pathnames with two (or more) slashes in Makefile.c, Jan Djärv, 2007/01/30
- Re: Pathnames with two (or more) slashes in Makefile.c, Sascha Wilde, 2007/01/30
- Re: Pathnames with two (or more) slashes in Makefile.c, Sascha Wilde, 2007/01/30
- Re: Pathnames with two (or more) slashes in Makefile.c, Sascha Wilde, 2007/01/31
- Re: Pathnames with two (or more) slashes in Makefile.c, Jan Djärv, 2007/01/31
- Re: Pathnames with two (or more) slashes in Makefile.c, Sascha Wilde, 2007/01/31
- Re: Pathnames with two (or more) slashes in Makefile.c, Jan Djärv, 2007/01/30
- Re: Pathnames with two (or more) slashes in Makefile.c, Sascha Wilde, 2007/01/30