A "temporary staging area" refers to the packages process -- if you intend
to package gcc in a RPM for example, you need to install it somewhere else
before you're going to install the real package on the system.
With chroot you can start programs (you don't trust or which might operate insecurely) under a special root directory. It's like a jail because the programs just run below this directory and can't access the files outside.
See http://www.linux-mag.com/2002-12/chroot_01.html for an in-depth explanation.
That's great! I didn't realise you could do something like that. Very useful for the future, thanks.
Well, the libstdc++ headers are more tightly coupled with the GCC they come with and that's why each gcc uses its own version by default. So, you will get a new c++ compiler with a shiny new c++ standard library.
I see.
I see. You're right of course, the filesystem hierarchy standard (http://www.pathname.com/fhs/) specifies that /usr/local should only be used for site specific software and no RPM from Redhat will write anything into this hierarchy (unless it's buggy).
Thanks for that link, I was thinking I should find some docs to learn about how the filesystem is structured. That looks ideal.
Try 'cat /dev/null | gcc -v -E -':
What is this doing?
It just preprocesses (the -E switch) an empty source file being verbose
about its operation (the -v switch) as you already found out.
What should it tell me?
The part I quoted just shows where the gcc that came with my Debian distribution searches for header files by default. Redhat's default gcc should behave the same. It just demonstrates that by default /usr/local/include is also searched for header files.
I see, do you know why is it that when I use -v for an empty file I get the following search paths:
#include <...> search starts here: /usr/local/include /home/jwatt/gcc/include /home/jwatt/gcc/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/include /usr/include
but when I use -v on an actual C++ file I get more search paths, specifically the following:
#include <...> search starts here: /home/jwatt/gcc/include/c++/3.2.3 /home/jwatt/gcc/include/c++/3.2.3/i686-pc-linux-gnu /home/jwatt/gcc/include/c++/3.2.3/backward /usr/local/include /home/jwatt/gcc/include /home/jwatt/gcc/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/include /usr/include
Actually, it means to read standard input, i.e. the output of `cat /dev/null'.
Ah, that makes more sense.
Can I add a more up-to-date version of the standard C++ library to gcc if I install gcc under my $HOME directory? Which version normally goes with gcc 3.2.3? Can anyone tell me how I would get my install of gcc to use this library automatically?
At first, you may use different C++ standard libraries with GCC. GCC by default ships with its own incarnation called libstdc++. With gcc 3.2.3 you get the GNU Standard C++ Library v3 (-3.2.x) which BTW does not work with any version prior to GCC 3.0.
There's also a commercial implementaion of the C++ STL from Dinkumware for
GCC and there's STLport (www.stlport.org) which is available for free.
STLport should also work with gcc 2.96 and provides more backward compatibility and obsolete features (e.g. vector iterators are implemented as pointers -- yes, this is not assured by the C++ standard, but some (broken) programs do rely on that).
The bottom line is that you can definitely install GCC 3.2 and expect that you get a more up-to-date version of the standard C++ library with it and there's no need to specify any special options.
Cheers.
I think I will stick with the library that comes with gcc 3.2.3 for the moment.
Thanks for all that Claudio.
Jonathan
