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

[Jonathan Watt]

Claudio Bley wrote:

> On Wed, Feb 18, 2004 at 07:54:00PM +0000, Jonathan Watt wrote:
> 
>>Claudio Bley wrote:
>>
>>>On Wed, Feb 18, 2004 at 01:48:06PM +0000, Jonathan Watt wrote:
>>>Oh man, redhat and the joy of RPM. ;-)
>>>
>>>Usually, gcc RPMs are not designed to be installed side by side and hence
>>>they usually can't.
>>>
>>>But there are various possibilities:
>>>
>>>1) just install without RPM; gcc will then install by default to 
>>>/usr/local.
>>>Additionally you could use checkinstall which generates an RPM for you from
>>>the `make install' process that you can install and remove just like other
>>>RPMs.
>>>
>>>2) upgrade to RH 8.x and use the compat-*-7.3 RPMs. That way you'd have the
>>>default gcc (3.2 IIRC) plus the old compiler for RH 7.3.
>>>
>>>3) edit the .spec file(s) of the gcc SRPM (just *install* the src.rpm and 
>>>edit
>>>the file(s) in /usr/src/redhat/SPECS)  and alter the `configure' options. 
>>>
>>>E.g. you could specify a custom install location (e.g 
>>>"--prefix=/usr/gcc32")
>>>or add a custom suffix to the binaries (e.g. --program-suffix=-3.2) and
>>>install the libstdc++ files to a different location (e.g.
>>>--with-gxx-include-dir=/usr/include/c++/3.2). You may also combine some of
>>>these and specify other options of course; RTFM. 
>>>
>>>Then do `rpmbuild -bb <spec-file>' (you may also specify --target PLATFORM
>>>in order to optimize for e.g. i686). 
>>>
>>>You may also have a look at the spec files for the compat-gcc src RPM how
>>>they manage that sort of thing and what configure options they use.
>>>
>>>
>>>I'd say if you don't want to distribute the RPM afterwards options 1 or 2
>>>sound preferable. Or just install Debian -- it's a lot more fun ;-)
>>>
>>>Also note that C++ libraries generated with g++ 2.96 are not ABI compatible
>>>with g++ 3.x and you can't link with them. 
>>>
>>>You need to be more verbose about the error message, I think rpmbuild keeps
>>>a log of the build process somewhere. A build error often suggests that
>>>you're missing required packages, but that's just a shot in the dark.
>>>
>>>HTH
>>
>>
>>Unfortunately I am not in a position to upgrade the operating system so 
>>suggestion 2 is a no-go. I have tried to pursue suggestion 1 since 
>>uninstalling and redistribution aren't an issue. I assume you meant I 
>>would have to build from source, so I downloaded it and used the 
>>following commands (I didn't use any options):
>>
>>./configure
>>make bootstrap
> 
> 
> Hm, according to the installation instructions it is not supported to build
> GCC in its source directory. Maybe you meant to run something like
> ../gcc-src/configure by the configure line above or you were just lucky
> enough that the built succeeded.

Sorry, that was slightly misleading. I did use a build directory. I just 
meant I didn't use any options.

>>Everything seems to have gone okay (at least it didn't terminate with an 
>>error message). Am I correct in thinking that if I now do 'make 
>>install', all the files - including library files for the standard C++ 
>>library etc - will be installed below /usr/local? 
> 
> 
> Yes.
> 
> 
>>What will the directories be? 
> 
> 
> lib files into /usr/local/lib; gcc specific libs in /usr/local/lib/gcc-lib
> include files into /usr/local/include
> 
> etc.
> 
> Just do a 'make -n install' to see what would be done.

That command gave me a flood of far, far too much information to 
decipher. But I assume there are other directories, for example I assume 
the binaries go in /usr/local/bin? Would you, or anyone else, know what 
they are?

>>I absolutely must not overwrite the gcc 2.96 files.
> 
> 
> Eventually, in the worst case you could alwys re-install the gcc-2.96 RPM
> files...

Okay, that's reassuring.

> If you're really paranoid about this you could just change permissions on the
> /usr/local directory and do "make install" with an unprivileged user.

Wouldn't I also need to change the privileges on the other existing 
directories that the install will need to write to, like 
/usr/local/include? Another reasons for wanting to know about all such 
directories.

>>(usr/local/bin is empty but in my $PATH if that is important).
>>
>>Also what will the new version of gcc be called? gcc3? When other users 
>>use gcc 2.96 will they be able to use 'gcc ...' without specifying 
>>include directories for the old libraries, and will I be able to use 
>>'gcc3 ...' (or whatever) without specifying include directories for the 
>>new libraries? I'm not exactly clear on what is going to happen as you 
>>can see. :)
> 
> 
> The new gcc will be called `gcc'. But appending a specifc suffix to all the
> binaries (cpp, gcc, gccbug, gcov, g++, ...) should work after installation.

Interesting, I would never have thought you could do that. I don't know 
if I will do that this time, but that knowledge could come in very 
useful at some point in the future!

> You could have used the --program-suffix option to "configure" I mentioned
> in my last mail. Re-running configure before "make install" with only this
> option might also just work without needing to recompile.

Interesting again, but I wont try if you aren't sure. :)

> The point is that usually /usr/local/bin should be *before* /usr/bin in the
> PATH. So, the new gcc will supersede the old compiler because it just comes
> first and users automatically get the new gcc unless they specify it with a
> concrete path.
> 
> 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. 

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.

>>Many thanks for your helpful reply,
> 
> 
> You're welcome. :-)
> 

Again, many thanks for your detailed and helpful reply,

Jonathan