As far as CPUs go, we have some options. Pentium 4, Pentium D, and Intel
Xeons are my three choices at the moment (I'm still not an AMD fan but
I'll consider it too) as they offer nice amounts of speed for reasonable
prices. The question is if we really need dual CPUs or not. They are
nice
I would like to hear from Jim and everyone working on the header project
regarding this possibility:
Find the headers that llh currently lacks that glibc-2.3.6 and
linux-2.6.16.x both support and patch them into llh. The only thing that
comes to mind is inotify support. Headers that have
On Mon, Apr 10, 2006 at 01:28:48PM -0600, Jeremy Herbison wrote:
If I recall correctly, the kernel headers were unpacked into
/tools/glibc-headers before glibc in chapter 5, and glibc used
--with-headers=/tools/glibc-headers for both chapter 5 and 6. That's it;
easy.
Which book
Dan Nicholson wrote:
To finish this thought, alpha will touch a lot of files once Chris'
dependency info goes in. The build commands are essentially the same
except one change in perl. However, I think only chapters 5 and 6 are
the only files affected, so there may not be that many
Beekmans
Although not in the book, I like to (for instance) build gpm before
ncurses. This also necessitates moving up Bison (and M4) since gpm needs
it. Basically, I'm just pointing out the usefulness of having Bison as
early in the build as possible.
Jeremy Herbison
--
http://linuxfromscratch.org
Here is another argument: Without the UTF-8 patch, there is still
Partial (broken) UTF-8 support in the book. Some packages already
enable UTF-8 (gettext, bash, glibc etc), and the testsuites
require some UTF-8 locales. Thus, anyone who wants the UTF-8 patch
removed should be responsible for
I give a +1 now. The support issues alone, such as I built non-utf8,
how can I add it now?, are enough to make me want it default on. The
alternative solutions, such as an appendix, won't solve this support
issue either. Having two separate books seems like a waste. For now,
Alexander's
Jim said:
Talking to community members in cross-lfs, most of them don't want to be
forced to use utf-8, because they don't need it. Others want to be able
to test it, and if they don't like it do a build without it.
No one is being forced to use utf-8. They're just building a utf-8
compatible
Alexander wrote:
Basically, it means that we have three options WRT udev and hotplug.
1) Upgrade to their new way of handling things, (i.e., linux-2.6.15 +
patches, new udev, new rules, no hotplug).
2) Keep everything as it is currently (i.e., linux = 2.6.12, udev,
current rules,
Dan Nicholson wrote:
Recently when doing some ICA on e2fsprogs I noticed that /sbin/e2fsck
is statically linked. Is this what we want? I might need a solid
blow from the cluebat, but seems most of the time we make shared
binaries when possible. e2fsprogs builds both a shared and static
Jeremy Herbison wrote:
Except that you typically run fsck on an unmounted disk, so a fsck
binary
on the damaged partition isn't going to help you, whether it is linked
to
other libraries or not.
So tell me how you run fsck on your root filesystem at startup if you
don't mount the disk
Jeremy Herbison wrote:
Okay, but in the event that it finds a problem, you'll still need a
recovery
disk of some sort. Or, if it can't run fsck at all because fsck is
linked to
a damaged .so, you'll know there is a problem anyhow and you'll STILL
need
a recovery disk with a different
Archaic Wrote:
Is it a warning or does it not run the tests? Or do the tests run and
fail?
They run anyhow... execscript for example simply has this in it:
if [ $UID -eq 0 ]; then
echo execscript: the test suite should not be run as root 2
fi
I don't know how running as root skews
The Bash 3.1 testsuite (not sure about previous versions) gives the
following warnings:
execscript: the test suite should not be run as root
exec7.sub: the test suite should not be run as root
test-tests: the test suite should not be run as root
A non-root user should be set up temporarily, much
I remember asking and finding a fix for this earlier, but can't find the
message anywhere.
Probably needs to be fixed in the book anyhow...
Since fixincludes are disabled, the GCC (pass 2) tests fail with:
make[1]: Entering directory `/mnt/chroot/tools/build/gcc-build/fixincludes'
autogen -T
The new fixincludes adjustments in chapter 5 don't work!
find ${GCC_INCLUDEDIR} -xtype d -exec rm -rf \{} \;
deletes all directories under and including
$GCC_INCLUDEDIR! It should be changed to:
find ${GCC_INCLUDEDIR}/* -xtype d -exec rm -rf \{} \;
Secondly, the GCC pass 2 testsuite will
I wrote:
The new fixincludes adjustments in chapter 5 don't work!
find ${GCC_INCLUDEDIR} -xtype d -exec rm -rf \{} \;
deletes all directories under and including
$GCC_INCLUDEDIR! It should be changed to:
find ${GCC_INCLUDEDIR}/* -xtype d -exec rm -rf \{} \;
Also, GCC_INCLUDEDIR
17 matches
Mail list logo
