Installing gcc-3.2.1, book 4.1, Ch 5. vs. Ch 6
 

Ok, I'm installing gcc-3.2.1 from Chapter 5.15. I am instructed to just unpack gcc-core for this and mkdir gcc-build and unpack and install from in there. Ok, fine.

Now I look ahead at Chapter 6.15 just for fun. There it says, "We will be building the C and C++ compilers at this time, so you'll need to unpack both the gcc-core and ccc-g++ tarballs." And it's recommended to create a gcc-build directory and install gcc into gcc-build.

I assume they mean to say, in Ch 6., ok, we will now also unpack gcc-g++ into that same gcc-build directory we created back in Chapter 5. That has to be right, right? And I don't have to do anything with the gcc-core at this point??

So now, in my case, I'll have a gcc-core-3.2.1 directory and gcc-g++-3.2.1 directory in that gcc-build directory. And the ./configure command in that section of chapter 6 is run down in that gcc-g++-3.2.1 directory. Or, is Chapter 6 saying to unpack gcc-core and gcc-g++ all into a single directory, gcc-build, and just have a file free-for-all in there?

Thanks...
:Pengy:

Ok, the reason you don't unpack gcc-g++ in chapter 5 is because you don't need the c++ compiler until later. So they're just compiling what they need, not the whole thing.

When you get to chapter 6, the un-tar of gcc-g++ will not create a new top-level directory. It will create more files and directories within gcc-3.2.1

If you keep the old source tree from your static compile (which I don't recommend), then no, you don't have to unpack the gcc-core tarball again. Just unpack the gcc-g++ package in the same directory you originally unpacked gcc-core. then cd into gcc-3.2.1, and run the configure/make commands as instructed.

Why I don't suggest keeping static compile source code around:
#1) The static versions of the packages will not actually be used in the final LFS system. They are only temporary, to enable you to work within the chroot environment.
#2) In previous versions of LFS, patches were applied to static programs, but not applied to the final programs (and vice-versa). In fact, they may do that in 4.1 as well. That means, you have an unecessary patch applied to the source code that you don't need, and (in the worst case) might cause problems once the system is finally built.

I used to think it was a typo/oversight when patches applied in chapter 5 were not applied in chapter 6. It isn't, and I learned that very well when I started having problems later.

If you want to keep the source code around, keep the final source code tree; get rid of the static tree.

Oh, ok, thanks, I'll keep that in mind when I get to Ch. 6.

Hmmmm... let's consolidate the discussion over here to avoid the hijacking mentioned in the other thread... :)

Ok, you've got the right idea about the different source trees. What I was getting at was this:
1. You unpack grep into /mnt/lfs/static/compile, creating a new grep subdirectory
2. You go into the grep subdirectory and configure/compile it for Chapter 5 (static linking)
3. You install grep, and go on to the next package
4. Fast-forward to chapter 6, grep install
5. Instead of unpacking grep again, you decide to reuse the source tree you created in step 1 (bad idea)
6. You cd into /mnt/lfs/static/compile/grep, run ./configure again with the new options, and compile

You run the risk of static/shared data mingling together in your final executable. You also run the risk of having a static-link patch applied when it's not supposed to be. What I was getting at was reusing the same source tree for the same package. Perhaps I'm over-the-top in this regard, but if I encounter an error during make, then I consider wiping the tree at that point as well. Simply because some of the code was compiled, but it obviously didn't get compiled with the right options since it died. I don't want the risk of that code tainting the final executable.

As a side not, I wanted to clarify something you metnioned in the other thread. You said the only directory in gcc-build was the gcc source tree. That's not what the book recommends. If I understand you comment correctly, you have something like this:
What the book suggests you have is this:

Ok, I'm not doing any of this under static. Static only gets the stuff that those --prefix=$LFS/static options put there, /bin, /lib, /include, etc.

Instead of :
I have:
And then ../static just has:
It does look more organized to me as I proceed. And it seems to be working. And the ../static directory 'looks' like a linux system.

I see your point about putting gcc-3.2.1, in this case, under ../temp, rather than in gcc-build. (But, I still don't see the evidence that it matters.)

And, like I said, at the end of Chapter 5, I will simply delete the stuff in ../temp and that way I will unpacked 'fresh' packages for Chapter6, as you are recommending.

Thanks for the discourse. It helps for me to 'talk it out" like this.

Edit: OOPS - dang formatting... oh, I used quote instead of code.

The danger in having the source code inside your build directory is this:

When the compilation starts, a hierarchy of directories and files can be created. Just like the source code itself has different directories that contain code to do specific tasks, the compilation environment can start creating directories to organize its work. There's the chance that during compile, one of those new directories or files may overwrite the contents of a source code file or directory.

The chances that it will happen? I don't know, but probably low. However, I doubt the developers gave any thought to what environment they would be compiled under. So it's up to the user to take whatever steps are felt to get a good compile. So, if you haven't run into a problem and the risk seems minimal (if existent at all), then you're good-to-go. However, if you do run into problems and ask someone for help, chances are good they'll suggest having parallel directories instead of nested ones... "just in case."

Then again, it could just be my paranoia. Again, I'm not saying what you're doing is right or wrong; just that it's not what the book suggests and that there are potential problems.

You know how sometimes you put stuff on the back burner...?

Well, that's what I did with this, and then today, reading in Ch. 6 in the book:

"The documentation that comes with Glibc recommends to build the package not in the source directory but in a separate, dedicated directory:"

Well, it just didn't click until after I read your post and combined that with this little sentence above. Now I see.

Thanks...

No problem...

I'm in the middle of post-configuring my LFS system. This is the third or fourth time I've built one. Each time I understand the process a little better. This time around I think I've got a pretty good idea of where I want to go and how I'm going to get there. So I lurk around here trying to spread any tidbits I've picked up.

Now it's off to grab a window manager. I just finished installing XFree86, and I have to decide between Enlightenment and Windowmaker...