Patchwork fix outdated path in cpp.texi

login
register
mail settings
Submitter Jonathan Wakely
Date Oct. 17, 2012, 11:41 p.m.
Message ID <CAH6eHdQ4zzwCCUgZMvLnv6fmZGvsCfgRsOxhfAwJ2+A8ThHmWQ@mail.gmail.com>
Download mbox | patch
Permalink /patch/192169/
State New
Headers show

Comments

Jonathan Wakely - Oct. 17, 2012, 11:41 p.m.
http://gcc.gnu.org/onlinedocs/cpp/Search-Path.html claims the search
path for C++ headers starts with /usr/include/g++-v3 which hasn't been
true for many years.

2012-10-18  Jonathan Wakely  <jwakely.gcc@gmail.com>

        * doc/cpp.texi (Search Path): Fix outdated C++ path.

Tested with "make doc html" - OK for trunk and the active branches?
commit 0361812a731853c926adfcaab2e68137b80b9a65
Author: Jonathan Wakely <jwakely.gcc@gmail.com>
Date:   Thu Oct 18 00:32:07 2012 +0100

    	* doc/cpp.texi (Search Path): Fix outdated C++ path.
Gerald Pfeifer - Oct. 21, 2012, 7:34 p.m.
On Thu, 18 Oct 2012, Jonathan Wakely wrote:
> http://gcc.gnu.org/onlinedocs/cpp/Search-Path.html claims the search
> path for C++ headers starts with /usr/include/g++-v3 which hasn't been
> true for many years.
> 
> 2012-10-18  Jonathan Wakely  <jwakely.gcc@gmail.com>
> 
>         * doc/cpp.texi (Search Path): Fix outdated C++ path.
> 
> Tested with "make doc html" - OK for trunk and the active branches?

I was going to say "Ack", since it's a doc patch, but somehow my
own tests on various platforms (FreeBSD, GNU/Linux,...) did not
confirm /usr/include/c++ in the search path. 

Or do you mean that it's at the root of some search paths, that
is /usr/include/c++/... instead of /usr/include/g++-v3 ?  (I
definitely have not seen the latter anywhere, so if it's this,
then it looks okay.)

Gerald
Jonathan Wakely - Oct. 21, 2012, 9:26 p.m.
On 21 October 2012 20:34, Gerald Pfeifer wrote:
> On Thu, 18 Oct 2012, Jonathan Wakely wrote:
>> http://gcc.gnu.org/onlinedocs/cpp/Search-Path.html claims the search
>> path for C++ headers starts with /usr/include/g++-v3 which hasn't been
>> true for many years.
>>
>> 2012-10-18  Jonathan Wakely  <jwakely.gcc@gmail.com>
>>
>>         * doc/cpp.texi (Search Path): Fix outdated C++ path.
>>
>> Tested with "make doc html" - OK for trunk and the active branches?
>
> I was going to say "Ack", since it's a doc patch, but somehow my
> own tests on various platforms (FreeBSD, GNU/Linux,...) did not
> confirm /usr/include/c++ in the search path.
>
> Or do you mean that it's at the root of some search paths, that
> is /usr/include/c++/... instead of /usr/include/g++-v3 ?  (I
> definitely have not seen the latter anywhere, so if it's this,
> then it looks okay.)

I get:

echo  | g++ -v -E -x c++  - 2>&1 | sed -n '/#include <...> search
starts/,/End of search list/p'
#include <...> search starts here:
 /usr/lib/gcc/x86_64-redhat-linux/4.6.3/../../../../include/c++/4.6.3
 /usr/lib/gcc/x86_64-redhat-linux/4.6.3/../../../../include/c++/4.6.3/x86_64-redhat-linux
 /usr/lib/gcc/x86_64-redhat-linux/4.6.3/../../../../include/c++/4.6.3/backward
 /usr/lib/gcc/x86_64-redhat-linux/4.6.3/include
 /usr/local/include
 /usr/include
End of search list.

And:

readlink -f /usr/lib/gcc/x86_64-redhat-linux/4.6.3/../../../../include/c++/4.6.3
/usr/include/c++/4.6.3

The g++-v3 path was correct for GCC 3.0 and 3.1 but not since then,
see http://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.v2_headers
Gerald Pfeifer - Oct. 28, 2012, 10:21 p.m.
On Sun, 21 Oct 2012, Jonathan Wakely wrote:
>> I was going to say "Ack", since it's a doc patch, but somehow my
>> own tests on various platforms (FreeBSD, GNU/Linux,...) did not
>> confirm /usr/include/c++ in the search path.
>>
>> Or do you mean that it's at the root of some search paths, that
>> is /usr/include/c++/... instead of /usr/include/g++-v3 ?  (I
>> definitely have not seen the latter anywhere, so if it's this,
>> then it looks okay.)
> I get:
> 
> echo  | g++ -v -E -x c++  - 2>&1 | sed -n '/#include <...> search
> starts/,/End of search list/p'
> #include <...> search starts here:
>  /usr/lib/gcc/x86_64-redhat-linux/4.6.3/../../../../include/c++/4.6.3
>  /usr/lib/gcc/x86_64-redhat-linux/4.6.3/../../../../include/c++/4.6.3/x86_64-redhat-linux
>  /usr/lib/gcc/x86_64-redhat-linux/4.6.3/../../../../include/c++/4.6.3/backward
>  /usr/lib/gcc/x86_64-redhat-linux/4.6.3/include
>  /usr/local/include
>  /usr/include
> End of search list.
> 
> And:
> 
> readlink -f /usr/lib/gcc/x86_64-redhat-linux/4.6.3/../../../../include/c++/4.6.3
> /usr/include/c++/4.6.3

Yep, just I first read the text as /usr/include/c++ itself being in
the include path (which it is not).  Of course, g++-v3 is even more
incorrecot :-), so the patch is fine.

Perhaps you can rephrase it a bit to help clarify that?  (But that
is optional; in any case, your patch improves what is currently there.)

Gerald
Jonathan Wakely - Oct. 29, 2012, 12:08 a.m.
On 28 October 2012 22:21, Gerald Pfeifer wrote:
> On Sun, 21 Oct 2012, Jonathan Wakely wrote:
>>> I was going to say "Ack", since it's a doc patch, but somehow my
>>> own tests on various platforms (FreeBSD, GNU/Linux,...) did not
>>> confirm /usr/include/c++ in the search path.
>>>
>>> Or do you mean that it's at the root of some search paths, that
>>> is /usr/include/c++/... instead of /usr/include/g++-v3 ?  (I
>>> definitely have not seen the latter anywhere, so if it's this,
>>> then it looks okay.)
>> I get:
>>
>> echo  | g++ -v -E -x c++  - 2>&1 | sed -n '/#include <...> search
>> starts/,/End of search list/p'
>> #include <...> search starts here:
>>  /usr/lib/gcc/x86_64-redhat-linux/4.6.3/../../../../include/c++/4.6.3
>>  /usr/lib/gcc/x86_64-redhat-linux/4.6.3/../../../../include/c++/4.6.3/x86_64-redhat-linux
>>  /usr/lib/gcc/x86_64-redhat-linux/4.6.3/../../../../include/c++/4.6.3/backward
>>  /usr/lib/gcc/x86_64-redhat-linux/4.6.3/include
>>  /usr/local/include
>>  /usr/include
>> End of search list.
>>
>> And:
>>
>> readlink -f /usr/lib/gcc/x86_64-redhat-linux/4.6.3/../../../../include/c++/4.6.3
>> /usr/include/c++/4.6.3
>
> Yep, just I first read the text as /usr/include/c++ itself being in
> the include path (which it is not).  Of course, g++-v3 is even more
> incorrecot :-), so the patch is fine.
>
> Perhaps you can rephrase it a bit to help clarify that?  (But that
> is optional; in any case, your patch improves what is currently there.)

Yes, libdir/gcc/target/version/../../../../include/c++/version would
be more accurate, because libdir is not necessarily /usr

I'll come up with something better ...

Patch

diff --git a/gcc/doc/cpp.texi b/gcc/doc/cpp.texi
index fa5989e..e05029b 100644
--- a/gcc/doc/cpp.texi
+++ b/gcc/doc/cpp.texi
@@ -856,7 +856,7 @@  requested with @code{@w{#include <@var{file}>}} in:
 /usr/include
 @end smallexample
 
-For C++ programs, it will also look in @file{/usr/include/g++-v3},
+For C++ programs, it will also look in @file{/usr/include/c++/@var{version}},
 first.  In the above, @var{target} is the canonical name of the system
 GCC was configured to compile code for; often but not always the same as
 the canonical name of the system it runs on.  @var{version} is the