Bryan Kadzban wrote:
> Not quite true anymore; 2.6.16 also includes some new syscalls (openat
> and friends) that will (may? probably "will") require changes in the
> userspace headers.
Most definitely, if you want them to be used that is :-) Tho' only
Glibc-2.4 and above has support for the new
On 3/9/06, Dragos Ionita <[EMAIL PROTECTED]> wrote:
>
> With regards to Chris' comment:
>
> > Except LFS isn't expected to be used on other platforms. That's what
> > CLFS is for.
>
> I know. I decided to not use CLFS as I am compiling from a PPC Linux
> system, so I didn't see the need to use the
Dan Nicholson wrote:
> Dragos, when you get to the Ch. 6 Readjustment, you will have to change
> a couple of the commands because they specifically referenct ld-linux.so.2,
> which you obviously don't have. Probably have to drop a ^ there, too.
The chapter 6 readjustment already leaves the "^" o
Archaic wrote:
> From what I've read, inotify is the only thing that keeps popping up
> and a patch will satisify that.
Not quite true anymore; 2.6.16 also includes some new syscalls (openat
and friends) that will (may? probably "will") require changes in the
userspace headers.
There may be othe
Jim Gifford wrote:
> I also noticed that LLH moves things from asm-generic and incorporates
> them into asm-{arch}, so that kinda of throws things off a little.
Just an idea, leave it seperate until the parsing is done then copy|move
the headers from asm-generic to asm-{arch}. This might be a lit
On Thu, Mar 09, 2006 at 11:11:41AM +, Matt Darcy wrote:
>
> If your considering the new 2.6.16 kernel as a justification to update,
> then surly the LLH / Raw headers should be a consideration, as moving
> everything else forward and keeping on the 2.6.12 headers seems a little
> odd.
Kee
DJ Lucas wrote:
already. But I'll volunteer for the bootscripts role if the group still
thinks that they should remain separate from main development.
I never made that a firm requirement but at the time it made sense to do
so. It'd allow a distinction between book editor and bootscripts
mai
Dan Nicholson wrote:
Very interesting. So, on gcc-4 with PPC, you don't have a separate spec
called *dynamic_linker ? Because on x86, it looks like this:
*dynamic_linker:
/tools/lib/ld-linux.so.2
(Obviously, I already did the adjustment.) I suppose LFS could leave the
^ out. Just seemed mos
On 3/9/06, Dragos Ionita <[EMAIL PROTECTED]> wrote:
> Archaic wrote:
>
> Sorry about that, I didn't have a look at 6.1.
> The specsfile code snippet is the following:
>
> "-m elf32ppclinux %{!shared: %{!static: %{rdynamic:-export-dynamic}
> %{!dynamic-linker:-dynamic-linker /tools/lib/ld.so.1}}
DJ Lucas wrote:
And in 0.6 version of the script I see this...don't know why yet:
diff -Naur linux-libc-headers-2.6.12.0/include/linux/ata.h
linux-headers-2.6.12.0/include/linux/ata.h
--- linux-libc-headers-2.6.1
The kernel is about to release 2.6.16 (they have been on 2.6.16-rc5 for
about two weeks now) so we are quite a bit behind there.
Yes, but any upgrade to the kernel will require a newer version of udev
which is why the udev_update branch was created.
If your considering the new 2.6.16 ke
Archaic wrote:
> Notice the difference between 6.1 and current trunk. Gcc-4 does
> have this at the beginning and the sed works. I would recommend
> pasting the relevant line from your ppc specs file so we can have a
> look.
Sorry about that, I didn't have a look at 6.1.
The specsfile code snippe
On Thu, Mar 09, 2006 at 09:51:15AM +0100, Dragos Ionita wrote:
>
> I've found that the reason for this is, that the sed substitute looks
> for "^/lib", however, in the specsfile created by dumpspecs, "/lib"
> isn't at the beginning of a line.
Notice the difference between 6.1 and current trunk. G
I'm currently building the udev branch of LFS and found that the specs file sed
substitute in chapter 5.7 fails.
I've found that the reason for this is, that the sed substitute looks for
"^/lib", however, in the specsfile created by dumpspecs, "/lib" isn't at the
beginning of a line.
Not sure i
14 matches
Mail list logo
