On Fri, 2006-05-26 at 10:11 -0400, George Boudreau wrote:
>
> > I gather few (security enabled)hlfs --> hlfs builds have been done. Yes,
> > I gave up fairly early in the glibc build on a security enabled kernel.
>
> I was worried I had misinterpreted Ryan's book when I created the
> jhalfs code for it. I had stopped testing once I could build and boot a
> hlfs partition. I assumed a hlfs->hlfs build would be the same..(oh so
> wrong)
> > This build I am doing the uclibc version, so I reused the security
> > enabled hlfs kernel and reported results. Sure, it was going to barf but
> > why is interesting. So I can always go back to the low security kernel,
> > but I'll try for a wheeze to get around that coreutils thing, because it
> > seems a shame to give up when I am nearly out of the woods.
> keep postiong
OK - To summarize:
All builds have been of the svn book with a security enabled kernel
usless otherwise mentioned
Hlfs -->hlfs build of glibc version
Localedef may fail (depending on your kernel) in Ch 5, throwing the
build and bombing out in glibc chapter 6. The chroot stuff at the
beginning of chapter 6 didn't work, but doing the real mounts of virtual
filesystems instead of the false ones does work. That seems to have
been fixed recently(?). Anyhow, I had to downgrade the kernel security,
replace the new headers with 2.6.12.0 (restart effectively) to get past
that. Then I hit the 2.6.14.6 "Kernel won't boot" bug on the patch
downloaded and ended up hacking frandom.c by hand after checking the
archives. That should really be fixed.
Using modern (2.6.16.16) kernel headers breaks glibc chapter 5 in a
mighty way. So you're stuck with the older headers, and that, I am sure,
is going to become an issue. I'm no programmer, but I can see trouble
coming there. Mind you, when I formed that opinion, I had not found the
missing asm-generic directory (see below)
OTOH, using uclibc, that works with the new kernel headers.
make mrproper; make config; make prepare (Undocumented as yet).
A patch to make help in the kernel would go well!
You need ~/linux-2.6.16.16/include/asm-generic/* as well as what the
instructions provide for to build uclibc. This might rescue glibc build
on the newer headers also. I don't know. uClibc otherwise fails to build
in chapter 5. Now my coreutils issue is that gcc from chapter 6 is
building <expletive deleted> so nothing works. This may push me into
updating to a later gcc version (about the _last_ edge I wanted to bleed
on:). jhalfs allows me build, and I'm busy as hell on the bench, so I
may try a few more next week. Kevin Day has sent me "The gospel
according to Kevin", and when I get browned off bugging you lot I'll try
his uclibc approach on a few particular programs. The new recipe
appears to be
uclibc-0.9.28 & gcc-4.1 & headers-2.6.16, but that's bleeding edge.
I tried uclibc-0.9.28 & gcc-3.4.5 & kernel headers-2.6.16 but that
didn't go. Gcc went fine in chapter 5, but chapter 6 barfed.
A neat move in the jhalfs thing would be to have a line like
grep -e 'Permission' -e 'Error' <log of program just made> and throw
them up on stdout after the build. If you have a perms error, everything
gets "Permission denied" , and Error 1 is ignored but it would be nice
to have them in your face.
And the hlfs-20051220 build of tail seems broken. I'm using it now for
the first time really, and it refuses to exit if you hit Ctrl C
tail -fn 20 <somefile> latches the terminal and hogs it. It has to be
killed from a separate terminal. Try it on the later builds. I will when
I get a chance.
--
With Best Regards,
Declan Moriarty.
--
http://linuxfromscratch.org/mailman/listinfo/hlfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
