On Sun, 8 Jan 2006, Ken Moffat wrote:
I'll look at reversing this and kicking gccbug into shape.
Done
--
das eine Mal als Trag?die, das andere Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above informatio
On 1/7/06, Ken Moffat <[EMAIL PROTECTED]> wrote:
> On Sun, 8 Jan 2006, Greg Schafer wrote:
>
> > PS. I'm really glad that Ken and Dan are applying ICA to LFS builds. It's
> > all good :-)
>
> /me wishes it was somebody else, or only Dan - this is all keeping me
> from cleaning up my ppc32 CLFS enou
On Sun, 8 Jan 2006, Greg Schafer wrote:
PS. I'm really glad that Ken and Dan are applying ICA to LFS builds. It's
all good :-)
/me wishes it was somebody else, or only Dan - this is all keeping me
from cleaning up my ppc32 CLFS enough to investigate an oops on my G5
(hardly anybody builds pp
Ken Moffat wrote:
> But certainly, you'll probably want r7257 (move grep before libtool) to
> fix a hardcoded '/tools' in the libtool script.
Yes, this is new as of libtool-1.5.22. I only noticed this yesterday
myself in my latest ICA run. The problem is triggered because the latest
libtool ta
On Sun, 8 Jan 2006, Greg Schafer wrote:
While it won't hurt in this instance, IMHO the current toolchain sequence
should not be meddled with in this fashion. God only knows how many years
it's taken us to get it to its current state :-) I believe it also reduces
toolchain education by taking awa
Ken Moffat wrote:
> I'm not sure I fully understand your point, you seem to be saying that
> gcc might be at risk from mktemp ?
Sorry, I guess I wasn't quite clear. What you've done is make a build
order change by inserting a questionable package smack-bang in the middle
of the toolchain seque
Ken Moffat wrote:
> But certainly, you'll probably want r7257 (move grep before libtool) to
> fix a hardcoded '/tools' in the libtool script.
Yes, that's probably fine. But really, if you're willing to spend time
running ICA's on anything, I'd rather it was focused on the alpha branch
so that we
On Sat, 7 Jan 2006, Jeremy Huntwork wrote:
Not to mention that order changes are being done in the alphabetical
branch so that we don't upset whatever we have working in trunk. Let's
focus ICA's and purity on the poorly named alphabetical branch and leave
trunk alone completely in this regard. T
On Sun, 8 Jan 2006, Greg Schafer wrote:
Author: ken
Date: 2006-01-07 15:12:20 -0700 (Sat, 07 Jan 2006)
New Revision: 7256
Modified:
trunk/BOOK/chapter01/changelog.xml
trunk/BOOK/chapter06/chapter06.xml
Log:
Build mktemp earlier, for gcc's gccbug which now wraps mktemp in 'if [ yes =
ye
Jeremy Huntwork wrote:
[snip]
Apologies for the poor trimming in the previous message.
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Greg Schafer wrote:
>>Author: ken
>>Date: 2006-01-07 15:12:20 -0700 (Sat, 07 Jan 2006)
>>New Revision: 7256
>>
>>Modified:
>> trunk/BOOK/chapter01/changelog.xml
>> trunk/BOOK/chapter06/chapter06.xml
>>Log:
>>Build mktemp earlier, for gcc's gccbug which now wraps mktemp in 'if [ yes =
>>yes ];'
> Author: ken
> Date: 2006-01-07 15:12:20 -0700 (Sat, 07 Jan 2006)
> New Revision: 7256
>
> Modified:
>trunk/BOOK/chapter01/changelog.xml
>trunk/BOOK/chapter06/chapter06.xml
> Log:
> Build mktemp earlier, for gcc's gccbug which now wraps mktemp in 'if [ yes =
> yes ];' instead of 'if [ n
12 matches
Mail list logo
