gcc install/upgrade question

Tue Nov 6 08:23:08 UTC 2007

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.

>  
>>>> I prefer --prefix=/usr/local/gcc42 over /opt anything.
>>> Read the FHS. /usr/local/<package> violates the FHS.
>> We're talking about Bruce on his own computer. He owns /usr/local and 
>> can do what he wants with it. Vendors don't get a vote.
> Yes, everybody has the right to shoot himself into his own foot.
> 
>>> Think of installing GCC on a "commercial *nix" (e.g. Solaris, AIX etc.).
>>> GCC is designed in a way such it installs to /usr/local/[bin|lib|...]
>>> that is doesn't collide with the OS-vendor's installation in
>>> /usr/[bin|lib|...].
>> He's not, and Linux does not follow commercial unix practice, and the 
>> FHS differs significantly from standard unix practice.
> FHS is a guideline trying provide a "standard unix practice". The fact
> that almost any admin implements his own "private conventions" is a
> different problem.

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.

There are quite a few contributors listed at the foot; I recognise 
several of them as being famous Linux people (and one is also famous in 
OS/2) circles. None has any obvious connexion to and of the free BSDs or 
to a commerical Unix vendor (except IBM, but those I know are at IBM 
work on Linux, not AIX).

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?

> 
>>>>  The vendor 
>>>> (Fedora in this case) is forbidden the use of /usr/local
>>> Right.
>>>
>>>>  (and 
>>>> /var/local) beyond the basic layout whereas vendors often use /opt.
>>> Right, because vendors want to install in parallel to the OS, and not to
>>> override the OS (such as GCC).

gcc is never part of the OS.
>>>
>>> ..., but this discussion is as old as the FHS exists. We won't solve it,
>>> either. All I can say: Don't install gcc to /usr/local/(bin|lib|...)
>>> unless you want to override the OS's setting. The devil is in the
>>> details.
>> For Bruce on his own machine, those are the standard places. Where else? 
>>   Certainly not /opt.
> I disagree. /opt/ is a perfect location for parallel
> installation. /usr/local is an appropriate location to override the
> system without distroying the OS-vendor's installation.

Installing gcc under /usr/local has no implications for the ordinary use 
of the system, software developers aside.

Here is a quote from the FHS:
/usr/local : Local hierarchy
Purpose
The /usr/local hierarchy is for use by the system administrator when 
installing software locally. It needs to be safe from being overwritten 
when the system software is updated. It may be used for programs and 
data that are shareable amongst a group of hosts, but not found in /usr.
Locally installed software must be placed within /usr/local rather than 
/usr unless it is being installed to replace or upgrade software in /usr.

Since this is not packaged software, and Bruce explicitly said he wants 
to use the official version and to be able to remove the new, this 
suggests to me that /usr/local is the official place.

Here is another quote:
/opt : Add-on application software packages
Purpose
/opt is reserved for the installation of add-on application software 
packages.
A package to be installed in /opt must locate its static files in a 
separate /opt/<package> or /opt/<provider> directory tree, where 
<package> is a name that describes the software package and <provider> 
is the provider's LANANA registered name.
Requirements
Directory
Description
<package>  Static package objects
   <provider>  LANANA registered provider name
The directories /opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib, 
and /opt/man are reserved for local system administrator use. Packages 
may provide "front-end" files intended to be placed in (by linking or 
copying) these reserved directories by the local system administrator, 
but must function normally in the absence of these reserved directories.

There seems to be some disagreement amongst Linux vendors as to what 
"add-on" means - some have used /opt for KDE & Gnome.

However, it does say "packaged software" and Bruce isn't packaging 
software, he's building & installing unpackaged software for a machine 
he administers.

-- 

Cheers
John

-- spambait
1aaaaaaa at coco.merseine.nu  Z1aaaaaaa at coco.merseine.nu
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375

Please do not reply off-list