This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Can't install gcc 3.2 alongside gcc 2.96 on Red Hat 7.3


On Thu, Feb 19, 2004 at 07:44:10PM +0000, Jonathan Watt wrote:
> Claudio Bley wrote:
> >
> >But, I just found out that you may just use 'make DESTDIR=path-to-rootdir
> >install' as mentioned at http://gcc.gnu.org/install/finalinstall.html to
> >have it install (temporarily) to a different location. 
> 
> I did read that bit, but seeing as I wasn't sure what a "temporary 
> staging area" or "chroot jail" are, or how I could use them, I didn't 
> try to use DESTDIR.

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.

> >>>The include directories are basically the same for both compilers except 
> >>>for
> >>>the libstdc++ headers. You should not have to specify any option to gcc 
> >>>in
> >>>order to let it find its specific headers or libraries. 
> 
> Why is it different for libstdc++ headers?

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.

> >>So gcc 2.96 uses /usr/local/include too? That doesn't seem to be the 
> >>case on my computer. How do the compilors tell which are their 
> >>(standard) headers and libraries? A file naming convention? I'm just 
> >>curious.
> >
> >
> >Yes, gcc 2.96 should search /usr/local/include too because it's a standard
> >system include directory. Generally, the /usr/local hierarchy is for use by
> >the system administrator when installing software locally.
> 
> By 'use' I meant does it add files to this directory when installed. :) 
> I guess it doesn't as I don't see any.

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).

> >Try 'cat /dev/null | gcc -v -E -':
> >
> >...]
> >#include "..." search starts here:
> >#include <...> search starts here:
> >/usr/local/include
> >/usr/lib/gcc-lib/i486-linux/3.3.3/include
> >/usr/include
> >[...]
> 
> 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 accidentally messed up the 
> build I made before I could test it (I will try again tomorrow once the 
> new build is done), but from the manual I see that it should output "the 
> commands executed to run the stages of compilation" and "stop after the 
> preprocessing stage". I guess the trailing '-' means that there are no 
> input files.

Actually, it means to read standard input, i.e. the output of `cat /dev/null'.

> >GCC itself does not supply many headers and libraries. Instead it uses the 
> >C
> >standard library of the system and other headers/libraries installed in the
> >standard locations (/usr/{include,lib} and /usr/local/{include,lib}) by
> >default.
> 
> Hmm. I didn't realise that. This could cause problems as my whole reason 
> for wanting a more up-to-date version of gcc was that the existing one 
> couldn't compile the C++ code I am working on. I kept getting error 
> messages about certain aspects of the standard library not existing (it 
> works using gcc 3.2 on a Mandrake 8.2 box).

I said standard "C" library, which usually is glibc (AKA libc6) on Linux
systems. You don't need to worry about the C++ library, it's a
totally valid reason wanting to update GCC in favor of having a more
up-to-date libstdc++.

> 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.
-- 
Claudio Bley                                 ASCII ribbon campaign (")
Debian GNU/Linux user                         - against HTML email  X 
http://www.cs.uni-magdeburg.de/~bley/                     & vCards / \


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]