* [patch] fix outdated path in cpp.texi
@ 2012-10-18 1:17 Jonathan Wakely
2012-10-21 20:30 ` Gerald Pfeifer
0 siblings, 1 reply; 6+ messages in thread
From: Jonathan Wakely @ 2012-10-18 1:17 UTC (permalink / raw)
To: gcc-patches
[-- Attachment #1: Type: text/plain, Size: 346 bytes --]
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?
[-- Attachment #2: patch.txt --]
[-- Type: text/plain, Size: 789 bytes --]
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.
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [patch] fix outdated path in cpp.texi
2012-10-18 1:17 [patch] fix outdated path in cpp.texi Jonathan Wakely
@ 2012-10-21 20:30 ` Gerald Pfeifer
2012-10-21 21:57 ` Jonathan Wakely
0 siblings, 1 reply; 6+ messages in thread
From: Gerald Pfeifer @ 2012-10-21 20:30 UTC (permalink / raw)
To: Jonathan Wakely; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [patch] fix outdated path in cpp.texi
2012-10-21 20:30 ` Gerald Pfeifer
@ 2012-10-21 21:57 ` Jonathan Wakely
2012-10-29 0:03 ` Gerald Pfeifer
0 siblings, 1 reply; 6+ messages in thread
From: Jonathan Wakely @ 2012-10-21 21:57 UTC (permalink / raw)
To: Gerald Pfeifer; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [patch] fix outdated path in cpp.texi
2012-10-21 21:57 ` Jonathan Wakely
@ 2012-10-29 0:03 ` Gerald Pfeifer
2012-10-29 0:43 ` Jonathan Wakely
0 siblings, 1 reply; 6+ messages in thread
From: Gerald Pfeifer @ 2012-10-29 0:03 UTC (permalink / raw)
To: Jonathan Wakely; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [patch] fix outdated path in cpp.texi
2012-10-29 0:03 ` Gerald Pfeifer
@ 2012-10-29 0:43 ` Jonathan Wakely
2012-10-29 0:49 ` Jonathan Wakely
0 siblings, 1 reply; 6+ messages in thread
From: Jonathan Wakely @ 2012-10-29 0:43 UTC (permalink / raw)
To: Gerald Pfeifer; +Cc: gcc-patches
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 ...
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [patch] fix outdated path in cpp.texi
2012-10-29 0:43 ` Jonathan Wakely
@ 2012-10-29 0:49 ` Jonathan Wakely
0 siblings, 0 replies; 6+ messages in thread
From: Jonathan Wakely @ 2012-10-29 0:49 UTC (permalink / raw)
To: Gerald Pfeifer; +Cc: gcc-patches
[-- Attachment #1: Type: text/plain, Size: 257 bytes --]
On 29 October 2012 00:08, Jonathan Wakely wrote:
> 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 ...
I've committed this to the trunk.
[-- Attachment #2: patch.txt --]
[-- Type: text/plain, Size: 800 bytes --]
commit 258a736d80af598109faeeeee44e55b057711d24
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.
diff --git a/gcc/doc/cpp.texi b/gcc/doc/cpp.texi
index fa5989e..c463e7c 100644
--- a/gcc/doc/cpp.texi
+++ b/gcc/doc/cpp.texi
@@ -856,7 +856,8 @@ 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{@var{libdir}/../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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-10-29 0:18 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-10-18 1:17 [patch] fix outdated path in cpp.texi Jonathan Wakely
2012-10-21 20:30 ` Gerald Pfeifer
2012-10-21 21:57 ` Jonathan Wakely
2012-10-29 0:03 ` Gerald Pfeifer
2012-10-29 0:43 ` Jonathan Wakely
2012-10-29 0:49 ` Jonathan Wakely
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).