Opened 13 years ago

Closed 12 years ago

Last modified 11 years ago

#2602 closed task (fixed)

GCC 4.4.1

Reported by: willimm Owned by: Randy McMurchy
Priority: normal Milestone:
Component: BOOK Version: SVN
Severity: blocker Keywords:
Cc:

Description

Version update to match the version in LFS 6.4.

4 things I want you to know:

  • gjar needs zip/unzip (covered in #2559)
  • The gmp and MPFR refrences need to be removed (covered in #2565)
  • Some packages need fixes for this version (covered in #2600)
  • And finaly, I am confiused to what version to update the tempoary GNAT. (Stay at 2005? 2006? 2007? 2008?)

Change History (19)

comment:1 by Randy McMurchy, 13 years ago

Owner: changed from blfs-book@… to Randy McMurchy
Severity: normalblocker
Status: newassigned

comment:2 by Randy McMurchy, 12 years ago

Owner: changed from Randy McMurchy to blfs-book@…
Status: assignednew

comment:3 by Randy McMurchy, 12 years ago

Milestone: 6.46.5

Modified milestone from 6.4 to 6.5

comment:4 by Randy McMurchy, 12 years ago

Summary: GCC 4.3.2GCC 4.4.1

Version increment to 4.4.1

http://ftp.gnu.org/pub/gnu/gcc/

comment:5 by DJ Lucas, 12 years ago

Owner: changed from blfs-book@… to DJ Lucas
Status: newassigned

comment:6 by DJ Lucas, 12 years ago

Owner: changed from DJ Lucas to blfs-book@…
Status: assignednew

Un-assigning myself from this ticket due to lack of knowledge regarding Ada and Fortran.

comment:7 by willimm, 12 years ago

I'd take on the Fortran part, but I don't know if we should upgrade ada at all.

comment:8 by willimm, 12 years ago

Fortran is easy, because it just needs GMP and MPFR, which is built as part of LFS anyway, so Fortran can be build as part of LFS. Ada, is however more complaticated, and I don't know what we will do for Ada.

William

comment:9 by Randy McMurchy, 12 years ago

Owner: changed from blfs-book@… to Randy McMurchy
Status: newassigned

comment:10 by Randy McMurchy, 12 years ago

It is unbelievable how much resources it takes to build all the compilers. I'm not done but started make and make check at 9:30am (went and worked all day), came home and it had finished at 5:10pm. On a fairly fast 32-bit machine. I'll have SBU's a bit later. I'm guessing about 100.

Used at least 3.7GB of disk. Wow!

comment:11 by DJ Lucas, 12 years ago

If a comparison would help, I get the following with gnat-gpl-2009-1 and --enable-languages=c,c++,ada,fortran,java,objc


dj [ ~/LFS/BLFS/BOOK-orig ]$ tail -n7 /sources/logs/0007-gcc-4.4.2 
real	174m14.222s
user	145m8.898s
sys	21m48.762s

Diskspace required with testsuite is:     (standard_in) 1: parse error
Diskspace required without testsuite is:  3351963103

dj [ ~/LFS/BLFS/BOOK-orig ]$ tail -n 5 /jhalfs/logs/032-binutils-pass1 
Totalseconds: 96


KB: 2043656	/media/lfs

dj [ ~/LFS/BLFS/BOOK-orig ]$ 
 

So about 109 SBU here. The without value looks just about plausible, unfortunately, I just now fixed the script (incorrectly named variable piped to paste, so bc got a "+ something + something").

-- DJ

comment:12 by Randy McMurchy, 12 years ago

I could not find a recent copy of binary gnat that I could use so I used the old 2005 copy I have. Doesn't matter. I'll look again, but everything I got from the libre (Gnu) site didn't have the necessary tools to build Ada.

Anyway, why didn't you build Objective C++ also?

comment:13 by DJ Lucas, 12 years ago

Don't know, guess I missed it, and that pretty much makes my results useless for comparison. I'm not doing anything tonight anyway, fixing to crash, so I'll correct my script once again and restart it in a few moments. As far as the GNAT version used, I selected linux-x86 (default), 2009 (default), and looked under "Files" for gnat-gpl-2009-1-i686-gnu-linux-libc2.3-bin.tar.gz.

http://libre2.adacore.com/dynamic/view/gnat-gpl-2009-1-i686-gnu-linux-libc2.3-bin.tar.gz?version=2009&config=x86-linux&filename=gnat-gpl-2009-1-i686-gnu-linux-libc2.3-bin.tar.gz

Since we are doing a 3 stage bootstrap and the testsuite, I'm _assuming_ that ADA is OK. I don't have any projects that I use that actually need ADA, so I haven't tested beyond the build. If there is a better test besides the compiler itself and testsuite, I'll be happy to give that a shot to test it out further tomorrow evening. Just let me know. Be home and on the machine around 18:00 CST.

-- DJ

comment:14 by DJ Lucas, 12 years ago

BTW, same for all the languages except for c, c++, and gcj (which does get a pretty darn good workout). Any suggestions for simple, easily testable apps would be good as an extra sanity check.

in reply to:  13 comment:15 by willimm, 12 years ago

Replying to dj@…:

Since we are doing a 3 stage bootstrap and the testsuite, I'm _assuming_ that ADA is OK. I don't have any projects that I use that actually need ADA, so I haven't tested beyond the build. If there is a better test besides the compiler itself and testsuite, I'll be happy to give that a shot to test it out further tomorrow evening. Just let me know. Be home and on the machine around 18:00 CST.

Well, Ncurses can build ADA bindings, but other than that, I don't know of any project which uses or needs ADA.

comment:16 by bdubbs@…, 12 years ago

I've taken a look at gcc in BLFS and have a couple of questions that may need to be addressed in the book.

  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.
  1. The currenet instructions have: --enable-languages=c,c++,ada,fortran,java,objc,treelang

This does not seem to be optimal. I suggest putting a placeholder here and having the user actively decide what languages to actually build. 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.

  1. It should probably be mentioned that JDK also provides Java capability so building that is an alternative to building gcc Java.
  1. 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.
  1. 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.

in reply to:  16 comment:17 by Randy McMurchy, 12 years ago

Replying to 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.

  1. The currenet instructions have: --enable-languages=c,c++,ada,fortran,java,objc,treelang

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.

  1. 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.

  1. 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.

  1. 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.

comment:18 by Randy McMurchy, 12 years ago

Resolution: fixed
Status: assignedclosed

Updated BLFS to GCC-4.4.1 which matches the LFS-6.5 version. I also incorporated Bruce's suggestions #3, #4, and #5 into the instructions.

comment:19 by (none), 11 years ago

Milestone: 6.5

Milestone 6.5 deleted

Note: See TracTickets for help on using tickets.