hello!

i have a problem during compiling gcc-3.2.3. (chapter 5 - lfs 4.1)
host system: mandrake 9.1

first i tried it with gcc-3.3 it works out until chapter 6. in the faq i read that 3.3 causes many problems, so i went back to chapter 5 to compile gcc-3.2.3 but i got the following error.

does anybody know what's wrong?

When you say you "went back to chapter 5", does that mean you stopped progress in chapter 6 simply to recompile gcc? Or did you exit the chroot environment and recompile it as if you were working through chapter 5 normally?

Things I would try:
Download the gcc source for 3.2.3 again.
Compile it using a clean source tree (remove the existing gcc 3.2.3 and 3.3 trees)
If that works, try to pick up where you left off in Chapter 6

HOWEVER, if it were me, I would probably start from scratch. From what it sounds like, you've tried using 3.3 as your main compiler, and actually compiled glibc using it before you ran into problems. Mixing compilers and libraries can sometimes have unexpected results. Starting over sucks, I know, but for pieces as critical as gcc and glibc, it's probably worth the frustration.

rimo, your post is confusing me a little. (And that's not hard to do. )

In the book, and on the CD, I bought from LFS, there are 2 packages, gcc-core-3.2.1.tar.bz2 and gcc-g++-3.2.1.tar.bz2. (Maybe I need to go read the faq if that changed.)

In Ch. 5 you install the 'core' package and then in Ch. 6 you install the 'g++' package, basically.

If it was me, I would now start from scratch also.


Dark Helmet, I think I understand about deleting the source tree, but I plan to wait until the end to do it. The files are just sitting there in a separate directory and aren't in the way anyway. Is there some significant reason to do it after each package install? And by source tree, in this instance, I mean /LFS/packages/temp/gcc-build/gcc-3.21. (Also, it seems the book recommendation to include a 'gcc-build' directory is unnecessary.)

regards...

hehe.... I just went to the faq and saw this:

3.3.

Can I use a version newer than the one in the Book?

If this is your first time building LFS, using a version not in the book or varying from the book in any way is not a good idea. The IRC channel regulars have a saying, "FBBG". As rms, the resident bot, is quick to say, this means, "Follow Book, Book Good." They and the people on the lists have helped many an unhappy newbie who deviated from the book during that first build.

Once you've built a system "by the book", you have a stable knowledge base from which to experiment to your heart's content (or pain, as is often the case.)


And,

gcc-3.3: Don't use this yet unless you're a developer and can fix errors because it breaks many packages.

I don't know, maybe you are a developer.

Well, when you compile any software from source, the compile process creates intermediate files. Those files were created based on the previous ./configure run. If you compile multiple times, but make a change between each (new/changed argument to configure, modification to some of the source) you run the risk of having some of that old, stale compile data working its way into the final executable. That can cause problems for obvious reasons.

Some source code offers a "make clean" target. That is supposed to get rid of everything, but relies on the developers to keep it up-to-date. Developers are more inclinced to write the code itself, and maintenance updates tend to be low priority, uninteresting tasks. While "make clean" is better than nothing, I still like to start with a new source tree whenever I recompile. It guarantees nothing is but a straight compile is included.

If you have successfully compiled some software and installed it, then yeah, you can leave the source tree around. Deleting it will free up space, but with the size of hardrives these days, it's probably a drop in the bucket. If you have to ever go back and recompile it, that's when I suggest getting rid of the tree. One other side benefit: if you ever start looking at the source code itself (to figure out what it's doing), it's nice to have a clean tree with nothing but the source.

Don't be so quick to discount the gcc-build directory... FBBG... I'm sure the LFS maintainers have good reason (probably from the gcc developers themselves) to continue creating that separate build directory.

Never underestimate the importance of a clean compile. It's a beautiful thing.

Right, but since each time I unpack (tar xjvf ../packagename.tar.bz2) a package into the /LFS/packages/temp directory, the unpacking creates a new directory for the package. And each directory has it's own ./configure and makeinstall, etc. For instance:
/LFS/packages/temp/gawk-3.11 has its own ./configure, etc.
/LFS/packages/temp/grep-2.5 has its own ./configure, etc.
And when I run ./configure, make, and make install, I am in the new directory. So, doesn't that avoid "having some of that old, stale compile data working its way into the final executable."? Or, do the intermediate files go outside that directory and get processed in a separate directory? And if that's the case, I don't know where it is to go and delete the files anyway.
Possibly I'll discover that, at the end of Ch. 5, I should delete the /LFS/packages/temp directory before proceeding, eh?

Right, but they probably didn't take into account the amazing itsjustme scheme. The only thing in the gcc-build directory is the gcc-3.2.1 directory. But, I'll use it anyway. FBBG!

Thanks...

(sorry, hope this isn't hijacking the original intent of the thread.)

Edit: Oh and the amazing itsjustme scheme is a result of discussions with Azmeen, so if it's wrong, it's all his fault.

it was much easier than i thought. i've tried different versions since two days and than i saw the real problem: i had simply forgotten to unpack the g++ package ^^. but thank you for your guesses.

my lfs is now finished but now i have two more errors during boot time.

1. this error occurs though i have not compiled usb support with the kernel.

2. in the faq they guess real time clock support causes this error but i have tried it twice - with and without RTC support.

could you help me once more?

greets rimo

it is a failure in the /etc/fstab file ...

Have you figured out the keymap problem? I'm afraid I don't have any experience with that kind of error, and would be very interested to know the solution if you've found one.

my keymap works... though some function keys don't work (i read that yo have to configure something extra ...) the chars etc. are there where they use to be
until now i have not found any problem caused by this error.

I found this in the FAQ, it might be of some help...

I was completely off about the keymap... I saw "char" in the error message and made the incorrect assumption it was character -> keymap related... oops!

http://www.linuxfromscratch.org/faq/#char-major-10-135

is there something else leading to this error?

Slap me next time I don't read all the posts in the thread. First I thought it was a keymap problem, and now I gave you a link to the FAQ when you clearly already saw it.

I had seen (might have been in the FAQ) that you could delete the /dev/rtc device file as another alternative. I probably haven't looked nearly as much as you have, but I'll give it another shot later today.

np

i've deleted the file /dev/rtc and now the error doesn't occur anymore - BUT what is RTC, what does it and do i need it?

Here's the FAQ

"char-major-10-135" refers to the character device, major 10, minor 135, which is /dev/rtc. It provides access to the BIOS clock, or RTC, the Real Time Clock. See /usr/src/linux/Documentation/rtc.txt for more information.

The error is because something, most likely hwclock, is trying to use /dev/rtc but you haven't configured kernel support for it in your kernel. Either delete /dev/rtc so hwclock won't try to use it or enable RTC support in your kernel. It's located in make menuconfig under "Character devices" -> "Enhanced Real Time Clock Support".

regards...

Edit: oops, I see Dark Helmet already posted this link.
Edit2: Just to clarify, the above text is directly copied from the FAQ, and is not something generated from my brain.