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