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 / \
