Bruce Dubbs wrote:
> I have completed my build using the new Chapter 5 methodology. It went
> perfectly. It booted to the proper command prompt, network worked, no
> warnings or errors.
>
> I've only checked the gcc test log and will check the others tonight.
> What else needs to be checked
On Mon, 23 Apr 2012 21:38:19 +0100
Jeremy Huntwork wrote:
> On 4/23/12 4:33 PM, Matt Burgess wrote:
> > The fix for this is to add
> > --with-native-system-header-dir=/tools/include to GCC's pass1 and pass2
> > builds so that it doesn't look at /usr/include at all.
>
> For the current build meth
Bruce Dubbs wrote:
> Matt Burgess wrote:
>> Hi,
>>
>> I don't think $subject should be particularly contentious, but thought
>> I'd send a request for approval/comments just in case.
>>
>> So, ticket #3066 states that on certain hosts Ncurses fails to build if
>> GPM is installed.
>>
>> This is bec
On Mon, 2012-04-23 at 16:34 -0500, Bruce Dubbs wrote:
> Pierre Labastie wrote:
> > Le 23/04/2012 22:34, Bruce Dubbs a écrit :
> >> Bruce Dubbs wrote:
> >>
> >>> It appears there are multiple ways to isolate the programs we need in
> >>> Chapter 6 to /tools. For us, the simpler the better. I think
Pierre Labastie wrote:
> Le 23/04/2012 22:34, Bruce Dubbs a écrit :
>> Bruce Dubbs wrote:
>>
>>> It appears there are multiple ways to isolate the programs we need in
>>> Chapter 6 to /tools. For us, the simpler the better. I think we ought
>>> to do a little more testing, but it's looking good.
Le 23/04/2012 22:34, Bruce Dubbs a écrit :
> Bruce Dubbs wrote:
>
>> It appears there are multiple ways to isolate the programs we need in
>> Chapter 6 to /tools. For us, the simpler the better. I think we ought
>> to do a little more testing, but it's looking good.
> I'm still in the initial bui
Le 23/04/2012 22:38, Jeremy Huntwork a écrit :
> On 4/23/12 4:33 PM, Matt Burgess wrote:
>> The fix for this is to add
>> --with-native-system-header-dir=/tools/include to GCC's pass1 and pass2
>> builds so that it doesn't look at /usr/include at all.
> For the current build method, I think it's on
Le 23/04/2012 23:01, Bruce Dubbs a écrit :
> Matt Burgess wrote:
>
>> '../gcc-4.7.0/contrib/test_summary>> $TEST_LOG 2>&1', hence giving the
>> appearance that the tests were run twice. I wonder whether that 2nd
>> command should just have 'role=nodump' in it to prevent jhalfs from
>> running it?
Matt Burgess wrote:
> On Mon, 2012-04-23 at 15:34 -0500, Bruce Dubbs wrote:
>
>> It did seem to run the tests twice. I don't know why. If we can get it to
>> run
>> once, it would save a lot of time. The results we identical on both runs.
>
> I don't think it did, Bruce. Were you looking at
On Mon, 2012-04-23 at 15:34 -0500, Bruce Dubbs wrote:
> It did seem to run the tests twice. I don't know why. If we can get it to
> run
> once, it would save a lot of time. The results we identical on both runs.
I don't think it did, Bruce. Were you looking at your jhalfs logs by
any chance
Matt Burgess wrote:
> Hi,
>
> I don't think $subject should be particularly contentious, but thought
> I'd send a request for approval/comments just in case.
>
> So, ticket #3066 states that on certain hosts Ncurses fails to build if
> GPM is installed.
>
> This is because the configure script i
On 4/23/12 4:33 PM, Matt Burgess wrote:
> The fix for this is to add
> --with-native-system-header-dir=/tools/include to GCC's pass1 and pass2
> builds so that it doesn't look at /usr/include at all.
For the current build method, I think it's only required for pass 2.
Given the difference of our
Bruce Dubbs wrote:
> It appears there are multiple ways to isolate the programs we need in
> Chapter 6 to /tools. For us, the simpler the better. I think we ought
> to do a little more testing, but it's looking good.
I'm still in the initial build, but the toochain seems to have done OK. One
Hi,
I don't think $subject should be particularly contentious, but thought
I'd send a request for approval/comments just in case.
So, ticket #3066 states that on certain hosts Ncurses fails to build if
GPM is installed.
This is because the configure script is apparently finding the GPM
headers o
On Mon, 23 Apr 2012 12:48:37 -0500, Bruce Dubbs wrote:
> I'm in the middle of a jh build right now. Just finishing up Chapter 5.
> I'll take a look when it completes. The toolchain built without complaint.
Thanks. Note that the sed added in r9799 masks the test failures so you may
want to re
Matthew Burgess wrote:
> On Mon, 23 Apr 2012 13:23:58 -0400, Jeremy Huntwork
> wrote:
>> On 4/23/12 1:11 PM, Pierre Labastie wrote:
>>> The reason is that /tools/bin/su cannot work for a normal user,
>>> because the setuid bit cannot be set at install in chapter 5 (if
>>> installing as user lfs).
On Mon, 23 Apr 2012 13:23:58 -0400, Jeremy Huntwork
wrote:
> On 4/23/12 1:11 PM, Pierre Labastie wrote:
>> The reason is that /tools/bin/su cannot work for a normal user,
>> because the setuid bit cannot be set at install in chapter 5 (if
>> installing as user lfs). Hence the choice of naming it
On 4/23/12 1:11 PM, Pierre Labastie wrote:
> The reason is that /tools/bin/su cannot work for a normal user,
> because the setuid bit cannot be set at install in chapter 5 (if
> installing as user lfs). Hence the choice of naming it su-tools, to
> prevent it to run (and fail) if the lfs user (who h
Le 23/04/2012 18:45, Jeremy Huntwork a écrit :
> This changelog entry on 2012-04-05 isn't quite correct. It reads:
>
> [matthew] - Use su from chapter 6 Coreutils in the Bash instructions,
> instead of the one from chapter 5. Install su as su rather than su-tools
> in chapter 5. Fixes #3057.
>
> co
On 4/23/12 12:45 PM, Jeremy Huntwork wrote:
> This changelog entry on 2012-04-05 isn't quite correct. It reads:
>
> [matthew] - Use su from chapter 6 Coreutils in the Bash instructions,
> instead of the one from chapter 5. Install su as su rather than su-tools
> in chapter 5. Fixes #3057.
>
> coreu
This changelog entry on 2012-04-05 isn't quite correct. It reads:
[matthew] - Use su from chapter 6 Coreutils in the Bash instructions,
instead of the one from chapter 5. Install su as su rather than su-tools
in chapter 5. Fixes #3057.
coreutils in chapter 6 doesn't install su. So the su you're
On 4/23/12 12:28 PM, Bruce Dubbs wrote:
> I also think we will need a paragraph or two in the "What's New" section
> explaining the changes.
Yeah, that might be good. Also a review of section 5.2 to make sure all
statements there are still correct.
JH
--
http://linuxfromscratch.org/mailman/lis
Jeremy Huntwork wrote:
> On 4/22/12 11:36 PM, Bruce Dubbs wrote:
>> gcc-pass2
>
> [snip]
>
>> Configure:
>> Remove -B/tools/lib/ from CC
>> Remove configure options
>> --with-native-system-header-dir=/tools/include
>> --without-ppl
>> --
On 4/23/12 12:00 PM, Jeremy Huntwork wrote:
> The --with-native-system-header-dir=/tools/include option is actually an
> addition, not a removal. Everything else looks like it's correct, Bruce.
> (I think I forgot to remove the startfiles patch from chapter 3 and the
> patches.ent. I'll take a l
W
On 4/22/12 11:36 PM, Bruce Dubbs wrote:
> gcc-pass2
[snip]
> Configure:
> Remove -B/tools/lib/ from CC
> Remove configure options
> --with-native-system-header-dir=/tools/include
> --without-ppl
> --without-cloog
The --with-native-syste
DJ Lucas wrote:
> Personally, citing the reasons above, I'd rather see the GNOME_PREFIX
> stuff gone, but if it really is wanted (even though its goal is not
> possible without heavy modifications) I suggest adding a warning, not a
> note, stating that $GNOME_PREFIX=/usr and $GNOME_SYSCONFDIR=/
DJ Lucas wrote:
> On 04/22/2012 10:36 PM, Bruce Dubbs wrote:
>> I've been studying Jeremy's changes and want to summarize them here.
>>
>>
>
>
> Asking for a technical review? :-) Both methods achieve the goal!
I wasn't asking for a technical review. I was studying the changes to
understand th
On Sun, 2012-04-22 at 19:02 -0400, Jeremy Huntwork wrote:
> Whether the resultant gcc actually operates slower is another question,
> although I doubt that too is significant, if so.
Out of the box (i.e. with default compiler flags), compile times will be
unaffected. Cloog and PPL are only used
28 matches
Mail list logo
