[BLFS Trac] #2602: GCC 4.4.1

BLFS Trac trac at linuxfromscratch.org
Wed Feb 17 10:13:41 PST 2010

#2602: GCC 4.4.1
 Reporter:  willimm  |       Owner:  randy@…                   
     Type:  task     |      Status:  assigned                  
 Priority:  normal   |   Milestone:  6.5                       
Component:  BOOK     |     Version:  SVN                       
 Severity:  blocker  |    Keywords:                            

Comment(by randy@…):

 Replying to [comment:16 bdubbs@…]:
 > 1.  Why are we rebuilding C and C++?  I don't know of any advantages of
 doing so unless the user is upgrading to a newer version of gcc.

 You must build C to build anything else, you cannot leave C off. We do C++
 simply so that all the compilers are built at one time. It may be that
 someone is upgrading from a different version. Not building C++ would be a
 bad thing.

 > 2.  The currenet instructions have:  --enable-
 > This does not seem to be optimal.  I suggest putting a placeholder here
 and having the user actively decide what languages to actually build.

 Why? It is mentioned to modify the line if you don't want any of the
 compilers. The same way it is done in all BLFS packages.

 >  I'd also go as far as telling a user that building the Ada, Objective
 C, treelang, Java, and FORTRAN compilers should only be done if they think
 they'll need it.  The only one of these I've needed is FORTRAN.

 Many government agencies still use Ada. Objective C is becoming popular,
 GCJ is becoming more widespread, I believe you can even make it into an
 SDK (JDK) as well. Treelang is obsolete. Again, why not just let the users
 choose what they want. That is, BTW, what I thought LFS/BLFS is all about.

 > 3.  It should probably be mentioned that JDK also provides Java
 capability so building that is an alternative to building gcc Java.

 In some cases, but not all. Don't have references handy, but trust me.
 There could be a note that there is a page for the Sun version of java in
 the Sun JDK. Keep in mind Bruce that only developers are going to
 reinstall/add compilers. Developers know what they are doing, or at least
 they should.

 > 4.  There should be a note that if you are building a kernel module,
 then the compiler should be the same one as used for the kernel build.  In
 other words, if you are going to upgrade gcc's C compiler, then rebuild
 your kernel too.

 That makes sense. The kernel and modules are fine the way they are,
 however if someone built a 3rd party module, then yes, there could be
 trouble. Otherwise, if the kernel is modified or modules need to be
 created, they will all be done using the new compiler. I don't see how
 there could be a mixup, unless someone did just a "make modules install"
 and then not install the new kernel, but that would be unwise. I will add
 a note. I've finished the page and about to commit, but I'll make the
 little note.

 > 5.  It follows that the user should be warned that when rebuilding the
 kernel, never reinstall the kernel's headers because glibc depends on the
 headers used when glibc was built.

 With all due respect, Bruce, kernel and glibc headers have nothing to due
 with rebuilding your compilers. The notes you mention to use belong on the
 kernel and glibc pages in LFS.

 I'm not being argumentative, I just don't see it necesssary to do most of
 the things you are asking.

Ticket URL: <http://wiki.linuxfromscratch.org/blfs/ticket/2602#comment:17>
BLFS Trac <http://wiki.linuxfromscratch.org/blfs>
Beyond Linux From Scratch

More information about the blfs-book mailing list