Can you safely remove GCC

[violentwind]

Hello, I was always under the impression that you shouldn't remove GCC, since it would break much of the OS.

Is this assumption wrong?

Can GCC be safely removed?

Thanks for any help,
Allen

[jayd512]

You should be able to remove gcc without breaking the existing system.
Not sure why you would want to remove it, though, since it may be needed for later updates or patches.

[MikeTbob]

I would not do that but if you do, please let us know how it goes. Sounds kinda wack.

[atreyu]

The way I see it, you can safely remove ANY package from a system, provided that you use that system's package manager to remove it. This presumes that you do not have any 3rd party or manual software installed that depends upon this software.

For example, I could remove gcc from my Fedora box:

rpm -e gcc

but it would fail b/c gcc-c++ package relies upon it. well, that's no big deal, i'd just remove them both:

rpm -e gcc gcc-c++

Although, you should really use yum to remove packages, if you use yum to install them.

(btw, you can force packages to be removed that complain about dependencies that you don't want to remove by using the --nodeps switch to rpm, but that is when you will start breaking your system)

The point is, you can always use the package manager to reinstall those same packages again, either the exact same versions, or updated versions of them. If there are config files that are owned by those packages, they are typically not removed by the package manager upon removal of the package. E.g. the config file /etc/vsfptd.conf for the vsftpd FTP daemon will get saved - if you modified it - and not removed, and when a new package is installed, that config file will not be overwritten.

Also, with rpm, you can do a dry run of erasing the package, to see what it would do:

rpm -e --test gcc gcc-c++

I'm sure there are similar test options for other package managers.

As to gcc itself, I don't see how that would break any packages, unless they were compiling packages that depended on gcc. You can typically query the package manager to see what package dependencies a particular package has, e.g.:

rpm -q gcc --requires

It will display a list of files and package names (and sometimes esoteric "things" that are neither but are provided by some other package). This is may be an unwieldy list of things, but it will give you more information about the package. Again, I'm sure other package managers provide similar capabilities.

[violentwind]

I would not do that but if you do, please let us know how it goes. Sounds kinda wack.

I agree, it does sound wacked, however, our prime has delivered us a product that they "somehow" built using gcc 4.5 on RHEL 6?!?! Now I can not get it to install on my RHEL 6.1 system due to dependencies on libstdc++, since mine is 4.4.6.

They suggest removing gcc-g++ and installing a libstdc++ rpm from FC14, but I'm not keen on this idea. So I thought that I could build gcc 4.5 on my own but I would want to install it in the default system space. This lead me to believe, either correctly or incorrectly, that I would have to first remove gcc 4.4 just to keep everything clean.

[Rubberman]

You can install more than one version of the gnu compiler tools on a system. I have 3.x, 4.4, and 4.5 on mine.

[MikeTbob]

Isn't there also a GCC backward compatible package?

[Rubberman]

Yes. On newer systems that would be 3.4. On Red Hat 5 systems that was 2.95 I think. I think that 3.4 has a 2.95 mode in order to build REALLY old code.

[atreyu]

They suggest removing gcc-g++ and installing a libstdc++ rpm from FC14, but I'm not keen on this idea.

I agree w/you, this is a horrible idea. They should give you the source RPM and allow you to rebuild it on your system. Or if they don't want to do that, they should build it for you on a RHEL6.x system of theirs and give you the resultant binary.

So I thought that I could build gcc 4.5 on my own but I would want to install it in the default system space. This lead me to believe, either correctly or incorrectly, that I would have to first remove gcc 4.4 just to keep everything clean.

You could make your own RPM of gcc version 4.5, using the RHEL spec file from gcc-4.4 and the stock gcc 4.5 source. Then you could use yum/rpm to upgrade your gcc 4.4 to 4.5 cleanly (ish).

It would probably be quicker to first try and install gcc 4.5 to an alternate location (like /opt or /usr/local) like has been suggested, and see if the customer RPM will then install. If that doesn't work, then maybe you'll have to roll your own RPM.

But my preferred solution would be to have the SRPM itself or have it rebuilt for your platform.

[Jonathan183]

The way I see it, you can safely remove ANY package from a system, provided that you use that system's package manager to remove it.

A package manager will manage packages for you ... it won't stop you destroying your system ! the package manager is also a package which can be removed ... just because you can doesn't mean you should

You are the system administrator ... not the package manager ...