LinuxQuestions.org
Go Job Hunting at the LQ Job Marketplace
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Linux From Scratch
User Name
Password
Linux From Scratch This Forum is for the discussion of LFS.
LFS is a project that provides you with the steps necessary to build your own custom Linux system.

Notices

Reply
 
Search this Thread
Old 07-19-2003, 04:51 PM   #1
itsjustme
Senior Member
 
Registered: Mar 2003
Location: Earth
Distribution: Slackware, Ubuntu, Smoothwall
Posts: 1,571

Rep: Reputation: 45
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...
 
Old 07-19-2003, 05:09 PM   #2
Dark_Helmet
Senior Member
 
Registered: Jan 2003
Posts: 2,786

Rep: Reputation: 369Reputation: 369Reputation: 369Reputation: 369
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.
 
Old 07-20-2003, 12:49 PM   #3
itsjustme
Senior Member
 
Registered: Mar 2003
Location: Earth
Distribution: Slackware, Ubuntu, Smoothwall
Posts: 1,571

Original Poster
Rep: Reputation: 45
Quote:
Originally posted by Dark_Helmet
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.
Oh, ok, thanks, I'll keep that in mind when I get to Ch. 6.
 
Old 07-20-2003, 01:29 PM   #4
Dark_Helmet
Senior Member
 
Registered: Jan 2003
Posts: 2,786

Rep: Reputation: 369Reputation: 369Reputation: 369Reputation: 369
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:
Code:
/mnt
 |- lfs
    |- static
       |- gcc-build
          |- gcc-3.2.1
What the book suggests you have is this:
Code:
/mnt
 |- lfs
    |- static
       |- gcc-build
       |- gcc-3.2.1
 
Old 07-20-2003, 02:03 PM   #5
itsjustme
Senior Member
 
Registered: Mar 2003
Location: Earth
Distribution: Slackware, Ubuntu, Smoothwall
Posts: 1,571

Original Poster
Rep: Reputation: 45
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 :
Code:
/mnt
 |- lfs 
    |- static
       |- gcc-build
I have:
Code:
/LFS
 |- static
 |- packages
    |- temp
       |- gcc-build
          |- gcc-3.2.1
       |- bash-2.05a
       |- binutils-build
          |- binutil-2.13.2
       |- bzip2-1.0.2
       |- (etc...)
And then ../static just has:
Code:
/LFS
 |- static
     |- bin
     |- i686-linux-gnu
     |- include
     |- info
     |- lib
     |- (etc...)
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.

Last edited by itsjustme; 07-20-2003 at 02:10 PM.
 
Old 07-20-2003, 04:55 PM   #6
Dark_Helmet
Senior Member
 
Registered: Jan 2003
Posts: 2,786

Rep: Reputation: 369Reputation: 369Reputation: 369Reputation: 369
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.
 
Old 07-22-2003, 09:40 PM   #7
itsjustme
Senior Member
 
Registered: Mar 2003
Location: Earth
Distribution: Slackware, Ubuntu, Smoothwall
Posts: 1,571

Original Poster
Rep: Reputation: 45
Quote:
Originally posted by Dark_Helmet
The danger in having the source code inside your build directory is this:
...
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...
 
Old 07-22-2003, 10:47 PM   #8
Dark_Helmet
Senior Member
 
Registered: Jan 2003
Posts: 2,786

Rep: Reputation: 369Reputation: 369Reputation: 369Reputation: 369
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...
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Which gcc-build.........is there another book? matthewa Linux From Scratch 4 04-06-2005 06:40 AM
Installing GCC-- digitalbrush Red Hat 2 12-23-2004 02:19 PM
good book on gcc / g++ durden2.0 Linux - General 3 01-25-2004 03:02 AM
Compile dmfe.c for installing net device driver on Book PC gogo Linux - Software 2 07-24-2003 12:51 PM
Installing GCC 3.1 over GCC 2.96...? aaronluke Linux - General 3 09-27-2002 05:28 AM


All times are GMT -5. The time now is 04:59 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration