> Thanks a lot Richard and Mark for such a detailed explanation. I am using > the "/usr/opt scheme" to build gcc .
Awesome. > Can i use the second scheme for any version of gcc, as currently its working > on 4.3.2? /usr/opt works for any release of any package (as long as the package works with it at all) >From here, this note gets long. Sorry. (Well ... not as long as my first reply in this thread.) > Also, when you said that the first scheme will update most other packages IN > PLACE, what do you mean by that? Did you ou mean to say that the binutils ... The first scheme (CSCRATCH) is totally different from the /usr/opt scheme. By "in place", I mean that it replaces the packages in their standard locations. It does not relocate them like /usr/opt does. It is only by coincidence that I had changed the logic for GCC and BINUTILS under that scheme to be installed in /opt/gcc and that it happened to fit what you were asking. If you built TCSH, for example, with CSCRATCH, you would get a new /usr/bin/tcsh which would replace your existing /usr/bin/tcsh. The original copy would be gone. BINUTILS in CSCRATCH is set to install under /opt/gcc even though it is built separately from GCC. Most packages built with CSCRATCH go under /usr or somewhere else in the operating system's file hierarchy. But I chose to place the assembler and C compiler under /opt/gcc. It simply makes those two packages easy to fence off from the rest of the system. I normally use /usr/opt for such trickery. ... > will be replaced, but the gcc wouldn't be? I like the first scheme, looks > like it will work on all platforms with all versions of gcc, but can you > clear the INPlace thing and does it have any consequences on the system? You can change CSCRATCH any way you like. It is just a crude wrapper around 'make' and the standard recipe. But it does not lend itself to multiple versions of a package the way /usr/opt does. I hope this helps. -- R; <>< On Tue, Jan 12, 2010 at 10:09, rui <[email protected]> wrote: > Thanks a lot Richard and Mark for such a detailed explanation. I am using > the "/usr/opt scheme" to build gcc . > > However, couple of queries: > Can i use the second scheme for any version of gcc, as currently its working > on 4.3.2? > Also, when you said that the first scheme will update most other packages IN > PLACE, what do you mean by that? Did you ou mean to say that the binutils > will be replaced, but the gcc wouldn't be? I like the first scheme, looks > like it will work on all platforms with all versions of gcc, but can you > clear the INPlace thing and does it have any consequences on the system? > > Regards, > Raja > > > > On Sat, Jan 9, 2010 at 6:02 PM, Richard Troth <[email protected]> wrote: > >> Building GCC is not difficult, but is time consuming. (MOST of the >> time is simply letting the build run while you go off and have a cup >> of coffee ... or a four course meal ... and dessert ... and take in a >> movie.) You will, of course, need a fully functional development >> environment before you can [re]build GCC. >> >> When it works, it is mostly unattended. When it doesn't work, you >> will have to take the time and figure out what broke. (Maybe you >> simply need to upgrade some other support utility. Who knows?) >> >> YES, you can have two versions of GCC on the same system. No problem! >> What you must do is have them in different locations. I use two >> schemes for building GCC, as follows, BOTH of which place GCC apart >> from the usual locations. Both of them will automagically download >> the GCC source for you. >> >> *** Using "CSCRATCH" to build GCC *** >> >> I often use this in-place build scheme which includes GCC (and >> BINUTILS, which you may also want to upgrade). It happens that the >> scheme I call CSCRATCH places GCC (and BINUTILS) under /opt/gcc rather >> than under /usr, so your old compiler would still be available. (And >> would in fact be the default.) Be aware that this scheme will replace >> most other packages IN PLACE. The fact that it relocates GCC is a >> happy coincidence that I won't elaborate on today. It is presently >> doing GCC 4.3.2. If you have a machine, which already has a compiler, >> you are welcome to try ... >> >> mkdir /tmp/csc >> cd /tmp/csc >> wget http://www.casita.net/pub/csc/makefile >> make gcc.mk >> make gcc.src >> make gcc.cfg >> make gcc.exe >> sudo make gcc.ins >> >> Then to run the new compiler, set it first in command search ... >> >> PATH=/opt/gcc/bin:$PATH ; export PATH >> >> You may want to do the same for BINUTILS which is at the 2.18.50.0.6 >> level. (And also lands safely under /opt/gcc.) >> >> *** Using "/usr/opt" to build GCC *** >> >> I also often use a non-intrusive scheme for building packages, >> including GCC, which lets you isolate things from the operating >> system. (So it does not break your box out of DPKG or RPM >> management.) Someone at Rice University came up with the basic idea >> years ago, and I have come to rely on it heavily. I found the build >> logic for GCC 4.3.2 for this scheme and uploaded it to the web. >> "/usr/opt" by design keeps everything AWAY FROM the operating system, >> so here too your old compiler would still be available. (And would >> again still be the default.) There are more steps (than with >> CSCRATCH), but this is a much more open-ended solution. >> >> mkdir /tmp/gcc-4.3.2 >> cd /tmp/gcc-4.3.2 >> wget http://www.casita.net/pub/gcc/gcc-4.3.2.mak >> cp -p gcc-4.3.2.mak makefile >> wget http://www.casita.net/pub/setup.sh >> cp -p setup.sh setup >> chmod a+rx setup >> make source >> make config >> make >> sudo mkdir -m 1777 /usr/opt >> make install >> ./setup >> >> Again, to run the new compiler, make it first in your command search ... >> >> PATH=/usr/opt/gcc/bin:$PATH ; export PATH >> >> You may want to do the same with "binutils-2.18.50.0.9". >> >> I do not know how well a home-grown GCC will behave w/r/t your mixed >> 32-bit and 64-bit environment. Personally, I would use one of the >> above methods and then rigorously test the stuff built by the new GCC. >> (Most of the libraries are outside of compiler space.) Rigorous >> testing is standard operating procedure, yes? :-) >> >> -- R; <>< >> >> >> >> >> >> On Fri, Jan 8, 2010 at 11:26, rui <[email protected]> wrote: >> > Hi all, >> > >> > I am looking for gcc 4.2 onwards on sles9 x86_64. Can I get a prebuilt >> gcc >> > or do i have to build it myself? if building is the way to go, what >> should >> > be the configuration options? >> > I would like GCC to have 64 bit libs - having 32 bit libs is useful, but >> not >> > necessary. >> > >> > Regards, >> > Raja >> > >> > ---------------------------------------------------------------------- >> > For LINUX-390 subscribe / signoff / archive access instructions, >> > send email to [email protected] with the message: INFO LINUX-390 or >> visit >> > http://www.marist.edu/htbin/wlvindex?LINUX-390 >> > >> >> ---------------------------------------------------------------------- >> For LINUX-390 subscribe / signoff / archive access instructions, >> send email to [email protected] with the message: INFO LINUX-390 or >> visit >> http://www.marist.edu/htbin/wlvindex?LINUX-390 >> > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO LINUX-390 or visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
