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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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

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

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.

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

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.

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. 

> Many thanks for your helpful reply,

You're welcome. :-)

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

[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux