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
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 [ no = yes
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.
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
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
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
