gcc install/upgrade question

Ralf Corsepius rc040203 at freenet.de
Tue Nov 6 09:27:02 UTC 2007

On Tue, 2007-11-06 at 17:23 +0900, John Summerfield wrote:
> Ralf Corsepius wrote:
> > On Tue, 2007-11-06 at 11:00 +0900, John Summerfield wrote:
> >> Ralf Corsepius wrote:
> >>> On Tue, 2007-11-06 at 08:00 +0900, John Summerfield wrote:
> >>>> Ralf Corsepius wrote:
> >>>>> On Mon, 2007-11-05 at 19:03 +0900, John Summerfield wrote:
> >>>>>> The standard way in this case is to follow the supplier's advice:FSF in 
> >>>>>> this case. It should install to /usr/local, well out of your way and 
> >>>>>> defined by standards to be used this way.
> >>>>> If you do this, you are replacing the "system compiler" with a local one
> >>>>> (/usr/local is special to gcc!). You will rarely want to do this under
> >>>>> linux.
> >>>> It's true that installing binaries to /usr/local/bin makes it the 
> >>>> default compiler, but you do get to choose with your PATH settings.
> >>>>
> >>>>> Much less error prone is to install to a 
> >>>>> prefix != /usr and prefix != /usr/local.
> >>>>>
> >>>>> The LSB recommended way would be to install to /opt or a subdirectory
> >>>>> thereof (e.g. --prefix=/opt/gcc42).
> >>> BTW: FHS would have been correct (my fault).
> >>>
> >>>> /opt commonly seems to be populated with rpms.
> >>>>  I'd keep out of it:
> >>> /opt is reserved for vendors. That's exactly what you act as when
> >>> installing additional packages in parallel to the one the OS vendor
> >>> installs.
> >>
> >> Bruce, the OP, was talking about doing this for his own use on his own 
> >> system. He's functioning as an administrator and not as a vendor.
> > Nit-picking. The difference is moot. It doesn't matter who builds a
> > piece of SW, whether he exercises "configure && make && make install" or
> > installs a pre-built tar-ball or rpm. The result to his system is the
> > same: A package is being installed.
> The difference is who manages it, and the scope of the problem, if any.
Which, on the technical, side makes no difference.

It doesn't matter "who" (admin, OS-vendor, 3rd party)
nor "how" (rpm, tar what ever), 
nor whether some thing is being distributed.
What matter is "what" == a package
"where" == how it cooperates with other pieces of SW (system

> FHS is at http://www.pathname.com/fhs/pub/fhs-2.3.html
> FHS is, apparently, edited by three people:
> Edited by
> Rusty Russell
> Daniel Quinlan
> Christopher Yeoh
> Copyright © 1994-2004 Daniel Quinlan
> Copyright © 2001-2004 Paul 'Rusty' Russell
> Copyright © 2003-2004 Christopher Yeoh
> The three are all famous in the Linux community, just ask Google if you 
> doubt me.
Yes, and ... why are you arguing? It's a
proposal/guideline/recommendation having been implemented by some
intelligent people with some linux background.

It's up to the user/admin/vendor to respect it or not - It's not a law,
but it also would not be a mistake to respect it.

Fedora tries to respect it, so users/admin also are better off
respecting it. However, it's their liberty not to do so.

> I would not expect Unix  folk, with over 30 years' customary practice 
> behind them are going to change their ways just because the Linux people 
> say they should, do you?
Nobody said the FHS is a law. Its a recommendation/guideline ... people
are free to respect it or not. ... yes, many people disagree with
details inside, and many admins and vendors prefer to obey their "grown
customary standards".

> gcc is never part of the OS.
Oh no, not this ole' discussion again ;)

Yes, this point is controversial. Some people don't consider a
system-compiler to be part of the OS, other do. POSIX considers it an
optional component of an OS's runtime envirionment.

> Installing gcc under /usr/local has no implications for the ordinary use 
> of the system, software developers aside.
Well, it has, because GCC comprises run-time libs.

Install a gcc with an incompatible ABI/API to /usr/local, use it to
compile, and you'll likely be watching your system going up in limbo.


More information about the fedora-list mailing list