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
