-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Jeremy Huntwork wrote:
>> (Actually it may cause grief with the installed distro's udev
>> system, especially if the wrong CONFIG_ compatibility sysfs flags
>> get unset...)
>
> So don't use udev on the host... [/me runs]
:-P
(You want to try
Bryan Kadzban wrote:
[snip]
Thanks for the clarifications, they were very helpful.
> Forcing the user to build the kernel before they start may work
I would think that doing this would provide optimal build results for
glibc. If you do it after the first pass of gcc, but before glibc, then
yo
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Jeremy Huntwork wrote:
> Bryan Kadzban wrote:
>> Ken Moffat wrote:
>>> but also I think we should encourage
>>> people to build a new kernel first (if they aren't using a Live CD)
>>> so that they can be sure it works with their .config, and the
Jeremy Huntwork wrote:
> Perhaps I'm not understanding your point. Certainly
> --enable-kernel=current would cover that very circumstance?
--enable-kernel=current breaks downgrades that are inevitable after any
RedHat release, and introduces a new variable into the build. That's why
I am agains
Bryan Kadzban wrote:
> Ken Moffat wrote:
>> To me, 2.6.9 is ancient history! (4 years old). I think something
>> like 2.6.16 (purely because it is still getting long-term support
>> updates) is a better minimum, but also I think we should encourage
>> people to build a new kernel first (if they
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Ken Moffat wrote:
> To me, 2.6.9 is ancient history! (4 years old). I think something
> like 2.6.16 (purely because it is still getting long-term support
> updates) is a better minimum, but also I think we should encourage
> people to build a
On Mon, Oct 20, 2008 at 07:24:50PM +0200, Gilles Espinasse wrote:
> Selon Ken Moffat <[EMAIL PROTECTED]>:
> ...
>
> LFS dev has on glibc --enable-kernel=2.6.0
> FC9 has set --enable-kernel=2.6.9
> Debian lenny has set --enable-kernel=2.6.18
> Greg has the same 2.6.18 setting on glibc chroot compil
Selon Ken Moffat <[EMAIL PROTECTED]>:
...
>
> In an *ideal* world, I still think that building the kernel version
> used in LFS on the host is the way to go. Doesn't fit every usage,
> but it has to be a lot better than attempting to support people
> building from some antique version of 2.6.
LF
Ken Moffat wrote:
> On Mon, Oct 20, 2008 at 10:36:14AM -0400, Jeremy Huntwork wrote:
>> * "Gcc-3.0.1" can at _least_ become "Gcc-2.95" I don't know if you
>> want to mention "egcs-2.91.66" but it works.
>>
> Possibly, but if you have to build a linux-2.6 kernel on the old
> host, you won't be a
Bruce Dubbs wrote:
> That's interesting Jeremy, but as a minimum, I wouldn't want to make the
> changes
> for LFS 6.4. I don't think you are proposing that but I wanted to make it
> explicit.
Yes, I wasn't aiming for 6.4. As I said, these changes will be going
into the jh branch. The only thi
On Mon, Oct 20, 2008 at 10:36:14AM -0400, Jeremy Huntwork wrote:
>
> * "Gcc-3.0.1" can at _least_ become "Gcc-2.95" I don't know if you
> want to mention "egcs-2.91.66" but it works.
>
Possibly, but if you have to build a linux-2.6 kernel on the old
host, you won't be able to build a recent v
Jeremy Huntwork wrote:
> So after some testing on a Redhat 6.2 system, I can say definitely that
> our host pre-reqs are higher than they technically need to be. I'd like
> to eventually drop all the below changes into the jh branch, but I just
> wanted to give a little status report first, for
Hello,
So after some testing on a Redhat 6.2 system, I can say definitely that
our host pre-reqs are higher than they technically need to be. I'd like
to eventually drop all the below changes into the jh branch, but I just
wanted to give a little status report first, for those interested.
Firs
13 matches
Mail list logo
