Dan Nicholson wrote:
> On 4/24/06, Randy McMurchy <[EMAIL PROTECTED]> wrote:
>> Randy McMurchy wrote these words on 04/22/06 12:45 CST:
>>
>>> We have GCC-3.3.6 in the book. This would probably be adequate, but
>>> I'm wondering if we shouldn't add GCC-3.4.6 to the book,
>> I just couldn't get exci
Dan Nicholson wrote:
> The situation you describe doesn't seem like it would have that
> drastic of an effect on more than a couple packages.
IIRC, it really only had an effect on the "large" packages (gcc, glibc,
etc.). And (again IIRC) it wasn't drastic; it was on the order of an
SBU or so.
So
On 4/24/06, Bryan Kadzban <[EMAIL PROTECTED]> wrote:
>
> Have the SBU numbers been updated at all since 6.1 or 6.1.1? If not,
> those book versions still use gcc 3.4. If gcc 4's bootstrap takes a lot
> longer than gcc 3.4's did, then that could explain the higher SBUs when
> building gcc 4.
gcc-
M.Canales.es wrote:
> What I can't undestart is that the book SBU values are smallest that
> mine :-?
Have the SBU numbers been updated at all since 6.1 or 6.1.1? If not,
those book versions still use gcc 3.4. If gcc 4's bootstrap takes a lot
longer than gcc 3.4's did, then that could explain th
On 4/24/06, Randy McMurchy <[EMAIL PROTECTED]> wrote:
> Randy McMurchy wrote these words on 04/22/06 12:45 CST:
>
> > We have GCC-3.3.6 in the book. This would probably be adequate, but
> > I'm wondering if we shouldn't add GCC-3.4.6 to the book,
>
> I just couldn't get excited about adding another
Randy McMurchy wrote these words on 04/22/06 12:45 CST:
> We have GCC-3.3.6 in the book. This would probably be adequate, but
> I'm wondering if we shouldn't add GCC-3.4.6 to the book,
I just couldn't get excited about adding another version of GCC to
the book. Instead, what I've decided to do,
M.Canales.es wrote these words on 04/24/06 15:32 CST:
> Not so badly. From your other post I think that the hardware used to do the
> builds has a bigger impact in the final values than the unpack of that small
> packages ;-)
Good point. But I tend to think BLFS.
Now do the same thing for the
El Lunes, 24 de Abril de 2006 22:25, Randy McMurchy escribió:
> > [EMAIL PROTECTED]: ~/build/Logs/LFS_Tools/gcc-4.0.2-Pass1 > cat sbu.time
> > 8.64 SBU
> And on my doggy 500mhz P3, just recently built (20060322):
>
> [EMAIL PROTECTED]: ~/build/Logs/LFS_Tools/gcc-4.0.3-Pass1 > cat sbu.time
> 9.38
El Lunes, 24 de Abril de 2006 22:10, Randy McMurchy escribió:
> > unpack additional packages (like libidn, bash-doc or vim-languages)
>
> To me, this skews things badly. We've never ever counted unpacking
> source tarballs before.
[EMAIL PROTECTED]:~/sources$ time { tar -xjf glibc-libidn-2.3.6.t
On 4/24/06, Randy McMurchy <[EMAIL PROTECTED]> wrote:
>
> And on my doggy 500mhz P3, just recently built (20060322):
>
> [EMAIL PROTECTED]: ~/build/Logs/LFS_Tools/gcc-4.0.3-Pass1 > cat sbu.time
> 9.38 SBU
Are you building on my box? :-) I got 9.2 SBU with a PIII-500 on
20060307, but I think I hav
Joshua Murphy wrote these words on 04/24/06 15:24 CST:
> theoretically, be
> within 3-4 of each other (between systems) at the worst.
In my opinion, it is much closer than that. Consistently. I'm at
less than 1 SBU difference between an Athlon 2400+ with 768mb RAM
and a 500mhz P3 with only 256mb
Randy McMurchy wrote these words on 04/24/06 15:17 CST:
> And I'm smack dab in the middle between y'all.
>
> [EMAIL PROTECTED]: ~/build/Logs/LFS_Tools/gcc-4.0.2-Pass1 > cat sbu.time
> 8.64 SBU
>
> [EMAIL PROTECTED]: ~/build/Logs/LFS_Tools/gcc-4.0.2-Pass1 > cat elapsed.time
> real24m40.135s
>
On 4/24/06, M.Canales.es <[EMAIL PROTECTED]> wrote:
> El Lunes, 24 de Abril de 2006 22:03, Dan Nicholson escribió:
>
> > >
> > > Approximate build time: 8 SBU
> >
> > I get 9.2 SBU for gcc-pass1. I didn't measure disk usage with those.
>
> Well, my time values can be smallest than yours due that I
Dan Nicholson wrote these words on 04/24/06 15:03 CST:
> On 4/24/06, M.Canales.es <[EMAIL PROTECTED]> wrote:
>> Approximate build time: 8 SBU
>
> I get 9.2 SBU for gcc-pass1. I didn't measure disk usage with those.
And I'm smack dab in the middle between y'all.
[EMAIL PROTECTED]: ~/build/Logs/L
El Lunes, 24 de Abril de 2006 22:03, Dan Nicholson escribió:
> >
> > Approximate build time: 8 SBU
>
> I get 9.2 SBU for gcc-pass1. I didn't measure disk usage with those.
Well, my time values can be smallest than yours due that I'm using an
HiperThreading enabled Intel CPU.
What I can't undes
M.Canales.es wrote these words on 04/24/06 14:40 CST:
> Disk usage is made in to steeps, a first "du -skx $LFS" before to unpack the
> package, and a second "du -skx $LFS" before to delete the sources and build
> dirs (excluding in both cases the jhalfs dir to not measure build log files).
So
On 4/24/06, M.Canales.es <[EMAIL PROTECTED]> wrote:
>
> That should to work. But comparing the values obtained from my last jhalfs
> build with the current ones in the book, the differences are abismal in some
> cases. For example, for GCC-pass1 in the book we have:
>
> Approximate build time: 4.4
Hi
I made some changes to jhalfs to do more accurate disk usage and build time
measurements. Due that into the editor's guide there is no mention (yet)
about how to do that measurements, I implemented the next approach:
Disk usage is made in to steeps, a first "du -skx $LFS" before to unpack t
Jeremy Huntwork wrote:
Give them the basics, show them how to extend, warn about possible
pitfalls and provide an example. Doing this we're not leaving them with
a half-baked system, as some have said already - we're teaching them how
to complete the system themselves which is what LFS has alw
Joshua Murphy wrote:
Finally, from personal experience, I can say that most people who come
to LFS don't do it to have a small, clean, fast, and stable system
(which is part of what they get), but instead go through the book,
doing the build, to understand how and why it works, something you can
On 4/21/06, Jim Gifford <[EMAIL PROTECTED]> wrote:
> In CLFS, we create all the users and groups, this will solve all issues
> if LFS will follow. It will also simplify the BLFS instructions to
> adding users to the appropriate groups. It's a plus for all, eliminates
> so of tedious work the BLFS h
21 matches
Mail list logo
