Message ID | CAH6eHdQ4zzwCCUgZMvLnv6fmZGvsCfgRsOxhfAwJ2+A8ThHmWQ@mail.gmail.com |
---|---|
State | New |
Headers | show |
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
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
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
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 ...
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