Dan Nicholson wrote:
> On 8/4/07, Shawn <[EMAIL PROTECTED]> wrote:
>> Dan Nicholson wrote:
>>> On 8/2/07, Shawn <[EMAIL PROTECTED]> wrote:
>>>> I've started to rebuild my linux box with 6.3-rc1 (Forgive me,
>>>> this email comes from my xp box.).
>>> Anyway, would you please try using the snapshot of the 6.3 branch
>>> that I created?
>>>
>>> http://www.linuxfromscratch.org/lfs/view/6.3-branch/
>>>
>> I've finished building my new lfs as per the book above. I didn't
>> find any major problems.
>
> Thanks for the help.
>
>> I just found a couple of minor things.
>>
>> 1. Section 6.12, p. 4. The link to the gcc build log is broken.
>
> That's partially a temporary thing. I suppose I should have copied
> the build logs, but for now you can view some here:
>
> http://www.linuxfromscratch.org/lfs/build-logs/development/
>
> But it looks like the 6.3-rc1 directory is empty there, too. I'll
> generate some logs before release, but the link should be fine.
>
>> I wonder if that sed is really needed to add -fomit-frame-pointer
>> to the gcc build. Isn't the final pass compiled with -g -O2, and
>> doesn't -O-anything imply -fomit-frame-pointer?
>
> I'd never noticed that before, but a little experimenting shows that
> on our dummy C program, this is not true.
>
> $ echo 'main(){}' > dummy.c $ gcc -g -O2 -c -o dummy1 dummy.c $ gcc
> -g -O2 -fomit-frame-pointer -c -o dummy2 dummy.c $ strip --strip-all
> dummy1 dummy2 $ cmp dummy1 dummy2 dummy1 dummy2 differ: byte 33, line
> 1
From gcc-4.1.2:
"-fomit-frame-pointer
Don't keep the frame pointer in a register...
<snip>
</snip>
Enabled at levels -O, -O2, -O3, -Os."
Well the documentation is misleading. Maybe the -g switch modifies the
behavior of -O. When I finish with blfs, I will disassemble the two
dummies and check it out. I would assume that candidate functions have
the epilogue/prologue modified for omit-frame-pointer. Anyhow, it
doesn't hurt. Obviously, something is changing, but one byte?
>
>> 2. 6.23, p. 1. A typo in the first paragraph.
>
> s/used used/used/'. Thanks. I also reworded it to not be so awkward.
> How would you like to be referenced in the Changelog?
Ha, for such a small thing. You must be kidding. :p
>
>> 3. 7.13.1. A minor point, but the description of the finding in
>> /etc/udev/rules.d/70-persistent-net.rules did not match what I
>> found. What I found was a single line (other than comments) that
>> assigned a name (eth0) by MAC address. Also, in this same section
>> there is a typo (I think). Anyhow, my rule looks like this.
>> SUBSYSTEM=="net", DRIVERS=="?*",
>> ATTRS{address}=="00:00:00:00:00:00", NAME="eth0"
>
> So, each device gets two lines: a comment description, then a udev
> rule. So, I guess it should be clearer that the first line is a
> comment. The rule looks correct and matches the description that I
> see. All you're missing is an ATTRS{type}, and it's described as
> optional. Which part exactly doesn't match what you expected?
7.13. Configuring the network script.
"Each NIC takes up two lines in the file. The first line is a
description of the NIC itself..."
Not in my output. Then...
"This line is a comment; neither the hardware ID nor the driver..."
"This line is a comment;" is throwing me off. Looking at my output I
might say:
"The file consists of a header and one or more rules. The header is a
comment that describes how the file was created. Each line in the header
is preceded by a "#" and can be safely ignored. Following the header are
the Udev rules, one or more lines for each NIC. Examining each rule, we
will notice that each NIC is assigned a unique name (e.g. NAME="eth0").
The "NAME" key is assigned the device name of the NIC."
or
"Examine each rule for the "NAME" key. A rule may consist of one or more
lines and the "NAME" key is usually found at the end of the rule. The
value assigned to this key is the device name of the NIC."
Since I only have one NIC, I cannot validate the "one or more lines"
statement. Maybe each rule consists of only one line? So I said "one or
more lines" to cover my ...
Anyhow, maybe I am way off base? Maybe I don't fully understand the rule
? So, my suggestions are given with due respect to the authors.
>
>> Good work gentlemen, and thanks for your hard work so that I can
>> learn.
>
> Thanks for testing. Feel free to send more comments if you find them.
>
>
> -- Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
