jhuntwork wrote:
> Initial addition of support for x86_64
???
This is nothing like the new build method at all. It appears you've taken
stuff from the old jh branch, which is now completely outdated because
it's based on the old build method.. Ughh. Not sure where you're going
dude, but this is
Rob Thornton wrote:
> Quote: "There's an internal issue with Coreutils which makes some of the
> programs behave abnormally if you build using an older kernel."
>
> It doesn't state what is considered "old." 2.2? 2.4? 2.6.xx.x?
Hard to say. Take a look at the patch.
"We provide a fallback for
Quote: "There's an internal issue with Coreutils which makes some of the
programs behave abnormally if you build using an older kernel."
It doesn't state what is considered "old." 2.2? 2.4? 2.6.xx.x?
I wasn't sure if this was worth making a ticket for.
Rob
--
http://linuxfromscratch.org/mailma
Jeremy Huntwork wrote:
> Greg, as I have your attention, I'm curious why the -fomit-frame-pointer
> change is still present in your second pass of gcc. I thought the
> purpose of this was to maintain compatibility between the first
> bootstrapped pass of gcc and the second pass?
GCC is no long
Greg Schafer wrote:
> Jeremy Huntwork wrote:
>
>> 1. Move to DIY's new build method in trunk. If we ignore multilib and
>> any extra arch support for this step, the changes required aren't
>> actually that many, and they all take place pretty early in chapter 5.
>
> I realize you say "this ste
Jeremy Huntwork wrote:
> 1. Move to DIY's new build method in trunk. If we ignore multilib and
> any extra arch support for this step, the changes required aren't
> actually that many, and they all take place pretty early in chapter 5.
I realize you say "this step", but LFS is already too far
Marc Ferland wrote:
> I hope this is the right mailing list for reporting spelling errors.
Yes, exactly the right place.
> I'm currently following LFS v6.4. in chap. 5.21
>
> The paragraph: "This parameter bypasses the search for mktime in configure
> and
> uses the version in glibc. The is ne
I hope this is the right mailing list for reporting spelling errors.
I'm currently following LFS v6.4. in chap. 5.21
The paragraph: "This parameter bypasses the search for mktime in configure and
uses the version in glibc. The is necessary due to a change in gcc that has
not been incorporated i
Gordon Schumacher wrote:
> Bruce Dubbs wrote:
>
>> Bryan Kadzban wrote:
>>
Ticket 2033 -- initramfs. This way people with crappy software "RAID1
cards" (e.g. Promise, Highpoint, etc.) that require drivers in Windows,
can still boot from those cards. Also, support for MD RAID (*
Bruce Dubbs wrote:
> Bryan Kadzban wrote:
>
>> > Ticket 2033 -- initramfs. This way people with crappy software "RAID1
>> > cards" (e.g. Promise, Highpoint, etc.) that require drivers in Windows,
>> > can still boot from those cards. Also, support for MD RAID (*real*
>> > software RAID ;-) ),
Bruce Dubbs wrote:
> Jeremy Huntwork wrote:
>> 1. Move to DIY's new build method in trunk. If we ignore multilib and
>> any extra arch support for this step, the changes required aren't
>> actually that many, and they all take place pretty early in chapter 5.
>> We can have trunk using the new b
Jeremy Huntwork wrote:
> * DESTDIR style PM support? (To me, this is the easiest way of offering
> a default pseudo-style PM support. We don't actually tell the users how
> to package up the binaries, track dependencies or track what is
> installed, but we do show whatever DESTDIR-compatible com
DJ Lucas wrote:
> Guys and gals,
>
> Is there any real desire to support the optional installation prefixes
> of X, QT, Gnome, and KDE in the book after package management enters?
> Maybe I'm just being lazy, but at this point, I kinda view it as an
> unnecessary maintenance burden. Not to me
Jeremy Huntwork wrote:
> Ok, so we have a fair amount of items we'd like to push into 7.0, some
> of which, work has already begun.
>
> As far as step-by-step plan of attack goes, how does this sound?
>
> 1. Move to DIY's new build method in trunk. If we ignore multilib and
> any extra arch sup
Selon Jeremy Huntwork <[EMAIL PROTECTED]>:
>
> 5. Ticket 2033. Include support for initramfs. Would this require a
> separate branch, and can it be worked on in parallel to other changes,
> or is it better to wait until other above changes are sorted out?
>
We have initramfs working on IPCop (with
64-bit would be pre for me. Every recent pc is capable of it and as
RAM exceeds 4GB or more, people want 64-bit to make full use of it.
That you can complile 64-bit code on 32-bit software, that has already
been made possible by CLFS, but that brings the problem that if the
host is 32-bit, you have
Matthew Burgess wrote:
> I've already got the trivial patch that upgrades Udev, but doesn't strip out
> Udev-config. It's been build-tested but not boot-tested currently. It may
> have an impact on the minimum host-kernel pre-req, but I don't have anything
> to test on to confirm/deny this. M
On Wed, 03 Dec 2008 07:22:48 -0500, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
> 4. Ticket 2284, upgrade of Udev, and strip out udev-config. I doubt this
> needs its own branch. What sort of time/work is involved here?
I've already got the trivial patch that upgrades Udev, but doesn't strip out
On Wed, 03 Dec 2008 00:42:36 -0600
DJ Lucas <[EMAIL PROTECTED]> wrote:
> As far as KDE is concerned, I'm really hoping that by the time BLFS is
> ramping up for 7.0, KDE-4 will be feature complete and that particular
> issue isn't one any longer.
Oh I do like humour on the lists So 7 is ta
Ok, so we have a fair amount of items we'd like to push into 7.0, some
of which, work has already begun.
As far as step-by-step plan of attack goes, how does this sound?
1. Move to DIY's new build method in trunk. If we ignore multilib and
any extra arch support for this step, the changes requi
Jeremy Huntwork wrote:
> What do you think is likely to happen in future versions and/or what is
> your plan?
GCC is not going to revert back, clearly.
> Just continue to maintain the backport patch for future versions?
Pretty much. It's similar in principle to the current specs handling ie:
ch
21 matches
Mail list logo
