hi...
a basic question.
fc6 comes with gc4.1 . i'm looking to test gc4.2, and would like to have a parallel dev environment so i have both 4.1 and 4.2.
i'm trying to find pointers on what needs to be done, to make sure i don't screw up the current 4.1 environment.
it appears that all i need to do is to set a prefix dir when i do the initial configure.
--./configure --prefix=/gcc42 --make --make install
this appears to place everything under the gcc42 top level dir. however, what will i need to do to actually be able to hook into the libs/objs created by the gcc4.2 build. what will i have to insert into my paths, or rather where should the information be placed.. in the bashrc/profile files/etc...
pointers/sites on this would be helpful. haven't been able to find a good site that walks through this...
once i test 4.2, i'll just rebuild, and rewrite gcc4.1. are there any issues that i'm going to run into when i do that!
thanks
bruce wrote:
hi...
a basic question.
fc6 comes with gc4.1 . i'm looking to test gc4.2, and would like to have a parallel dev environment so i have both 4.1 and 4.2.
i'm trying to find pointers on what needs to be done, to make sure i don't screw up the current 4.1 environment.
it appears that all i need to do is to set a prefix dir when i do the initial configure.
--./configure --prefix=/gcc42 --make --make install
this appears to place everything under the gcc42 top level dir. however, what will i need to do to actually be able to hook into the libs/objs created by the gcc4.2 build. what will i have to insert into my paths, or rather where should the information be placed.. in the bashrc/profile files/etc...
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.
pointers/sites on this would be helpful. haven't been able to find a good site that walks through this...
once i test 4.2, i'll just rebuild, and rewrite gcc4.1. are there any issues that i'm going to run into when i do that!
If the versions are in different locations, there is no problem at all. You'd choose the one you want by setting PATH appropriately.
You could even contemplate a virtual machine just for the occasion: over there, across the room, I have a 64-bit system running F8T3 for just this sort of thing.
On Mon, 2007-11-05 at 19:03 +0900, John Summerfield wrote:
bruce wrote:
hi...
a basic question.
fc6 comes with gc4.1 . i'm looking to test gc4.2, and would like to have a parallel dev environment so i have both 4.1 and 4.2.
i'm trying to find pointers on what needs to be done, to make sure i don't screw up the current 4.1 environment.
it appears that all i need to do is to set a prefix dir when i do the initial configure.
--./configure --prefix=/gcc42 --make --make install
this appears to place everything under the gcc42 top level dir. however, what will i need to do to actually be able to hook into the libs/objs created by the gcc4.2 build. what will i have to insert into my paths, or rather where should the information be placed.. in the bashrc/profile files/etc...
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.
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).
Ralf
hi ralf/all...
thanks for the replies. however, i'm not sure if anything else has to be done to be able to access the new gcc4.2 compiler/libs from the compiler. i'm pretty certain that i'd have to modify my env vars/paths, but i'm not sure where/what files...
any thoughts?
-----Original Message----- From: fedora-list-bounces@redhat.com [mailto:fedora-list-bounces@redhat.com]On Behalf Of Ralf Corsepius Sent: Monday, November 05, 2007 5:23 AM To: For users of Fedora Subject: Re: gcc install/upgrade question
On Mon, 2007-11-05 at 19:03 +0900, John Summerfield wrote:
bruce wrote:
hi...
a basic question.
fc6 comes with gc4.1 . i'm looking to test gc4.2, and would like to have
a
parallel dev environment so i have both 4.1 and 4.2.
i'm trying to find pointers on what needs to be done, to make sure i
don't
screw up the current 4.1 environment.
it appears that all i need to do is to set a prefix dir when i do the initial configure.
--./configure --prefix=/gcc42 --make --make install
this appears to place everything under the gcc42 top level dir. however, what will i need to do to actually be able to hook into the libs/objs created by the gcc4.2 build. what will i have to insert into my paths,
or
rather where should the information be placed.. in the bashrc/profile files/etc...
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.
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).
Ralf
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
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).
/opt commonly seems to be populated with rpms. I'd keep out of it:
07:56 [root@numbat ~]# rpm -qf /opt/Adobe/Reader8/bin/acroread AdobeReader_enu-8.1.1-1 07:56 [root@numbat ~]#
I prefer --prefix=/usr/local/gcc42 over /opt anything. The vendor (Fedora in this case) is forbidden the use of /usr/local (and /var/local) beyond the basic layout whereas vendors often use /opt.
bruce wrote:
thanks for the replies. however, i'm not sure if anything else has to be done to be able to access the new gcc4.2 compiler/libs from the compiler. i'm pretty certain that i'd have to modify my env vars/paths, but i'm not sure where/what files...
In general, I believe you'll need/want to set the three environment variables PATH, LD_LIBRARY_PATH, and MANPATH.
For convenience, in my .bashrc I do something similar to this:
toolspath() { local tools_path=/opt/tools export PATH=$tools_path/bin:$PATH export LD_LIBRARY_PATH=$tools_path/lib64:$LD_LIBRARY_PATH export MANPATH=$tools_path/man:$MANPATH }
I can then type 'toolspath' in a shell to have my environment variables set when I want to use/access the compiler and other tools I've installed.
Note that if you have other tools and libraries that you want to install along with your compiler and you don't want to include a path for each tool/lib (e.g. for /opt/gcc4.2.1, /opt/foo, /opt/bar, etc), then you might want to check into something like GNU stow.
From the web site http://www.gnu.org/software/stow/:
GNU Stow is a program for managing the installation of software packages, keeping them separate (/usr/local/stow/emacs vs. /usr/local/stow/perl, for example) while making them appear to be installed in the same place (/usr/local).
The nice thing about GNU stow is that it is easy to completely replace packages without worrying about leftover files littering a common directory structure.
Compilation and installation is a bit more complicated though. -- Steve Croll
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.
I prefer --prefix=/usr/local/gcc42 over /opt anything.
Read the FHS. /usr/local/<package> violates the FHS.
/usr/local/ traditionally is meant to be machine-local and meant to override the OS's defaults without destroying the OS-vendor's installation.
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|...].
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).
..., 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.
Ralf
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.
if he was packaging it for others outside his organisation, then he'd be functioning as a vendor.
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.
/usr/local/ traditionally is meant to be machine-local and meant to override the OS's defaults without destroying the OS-vendor's installation.
Exactly what Bruce wants to do.
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.
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).
..., 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.
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.
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.
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).
..., 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.
Ralf
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.
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 and "where" == how it cooperates with other pieces of SW (system integration).
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.
Ralf
hey people...
first of all, thanks to those who've replied.. 2nd.. it's gone way past what i was looking for, and is now in the realm of personal/academic blustering!!
Yes, there are valid points to being able to consistently setup your system with certain key packages, and knowing where they should/might go, and the repercussions of your actions when placing the packages in certain locations is a good thing to know!! But I would think that there are better places than this thread. At the very least, change the subject so if some one is looking for information on thiskind of conversation/topic, the user could find it more easily!!!!
But thanks anyway...!
-----Original Message----- From: fedora-list-bounces@redhat.com [mailto:fedora-list-bounces@redhat.com]On Behalf Of Ralf Corsepius Sent: Tuesday, November 06, 2007 1:27 AM To: For users of Fedora Subject: Re: gcc install/upgrade question
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 and "where" == how it cooperates with other pieces of SW (system integration).
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.
Ralf