Andrew Benton wrote:
Jeremy Herbison wrote:
Well, if you say so... I know it was in unstable at least, shortly after
kernel 2.6 was introduced.
Either way, can you see any technical reasons why that would not make
a good
stop-gap solution for inotify etc. support?
It was good enough for LFS
Jim Gifford wrote:
Another option here is to use the headers package I've been working
with a lot of people. It compiles a base LFS and CLFS with no issues
at all.http://ftp.jg555.com/headers/linux-headers-2.6.16.2.tar.bz2, or
roll your own by using http://ftp.jg555.com/headers/headers.
Jim Gifford wrote:
Yes, building both GCC 4.1 and Glibc 2.4 with them. I also have a few
others that have built it also.
Add another. Only minor changes to the LFS build, lsb patch for util
linux, glibc-libidn dir change, gcc specifics taken from Greg, groff
1.19.2, and probably a couple o
DJ Lucas wrote:
Jim Gifford wrote:
Another option here is to use the headers package I've been working
with a lot of people. It compiles a base LFS and CLFS with no issues
at all.http://ftp.jg555.com/headers/linux-headers-2.6.16.2.tar.bz2,
or roll your own by using http://ftp.jg555.com/headers
Jim Gifford wrote:
Another option here is to use the headers package I've been working with
a lot of people. It compiles a base LFS and CLFS with no issues at
all.http://ftp.jg555.com/headers/linux-headers-2.6.16.2.tar.bz2, or roll
your own by using http://ftp.jg555.com/headers/headers.
Jim
Andrew Benton wrote:
Looking at linux/socket.h in the tarball, it looks like this
#ifndef LINUX_SOCKET_H
#include
#endif
Renaming the variable $new_header in some places fixes the issue for me.
(I haven't had time to build with it yet)
Andy
--- /home/andy/headers 2006-04-11 07:24:04.
Jim Gifford wrote:
Another option here is to use the headers package I've been working with
a lot of people. It compiles a base LFS and CLFS with no issues at
all. http://ftp.jg555.com/headers/linux-headers-2.6.16.2.tar.bz2
I tried this and glibc failed to compile (in chapter 5) like this
Archaic wrote:
On Tue, Apr 11, 2006 at 10:11:19AM +0100, Matt Darcy wrote:
b.) multiple platforms to support - eg system built from 2.6.15 2.6.16
and 2.6.17-rc2 headers - then couple that with users deviating from the
book's package versions, well, it will just become unsupportable and not
hel
On Tue, Apr 11, 2006 at 10:11:19AM +0100, Matt Darcy wrote:
>
> b.) multiple platforms to support - eg system built from 2.6.15 2.6.16
> and 2.6.17-rc2 headers - then couple that with users deviating from the
> book's package versions, well, it will just become unsupportable and not
> help LFS'
Feldmeier Bernd wrote:
Hi All,
as for educational purpose I think
I would be good to use an original
kernel and then apply the header script.
This shows that there is some magic
around that stuff.
Releasing "only" a package is only
useful for advanced users I think.
regards Bernd
Surly that
Hi All,
as for educational purpose I think
I would be good to use an original
kernel and then apply the header script.
This shows that there is some magic
around that stuff.
Releasing "only" a package is only
useful for advanced users I think.
regards Bernd
Jim Gifford wrote:
> Another option
Jim Gifford wrote:
Another option here is to use the headers package I've been working with
a lot of people. It compiles a base LFS and CLFS with no issues at
all.http://ftp.jg555.com/headers/linux-headers-2.6.16.2.tar.bz2, or roll
your own by using http://ftp.jg555.com/headers/headers.
For
Archaic wrote:
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 t
Another option here is to use the headers package I've been working with
a lot of people. It compiles a base LFS and CLFS with no issues at
all.http://ftp.jg555.com/headers/linux-headers-2.6.16.2.tar.bz2, or roll
your own by using http://ftp.jg555.com/headers/headers.
--
http://linuxfromscratc
Archaic wrote:
> 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.
On 4/10/06, Dan Nicholson <[EMAIL PROTECTED]> wrote:
>
> Actually, gnome-vfs just checks
> for the existence of inotify.h. It has its' own internal copy called
> inotify-kernel.h that it uses.
Slight lie. The internal one is called local_inotify.h. It appears
that they used to try to include th
On 4/10/06, Archaic <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 10, 2006 at 01:46:49PM -0600, Jeremy Herbison wrote:
> >
> > Either way, can you see any technical reasons why that would not make a good
> > stop-gap solution for inotify etc. support?
>
> Yes. We can just add the inotify header and call
On 4/10/06, Andrew Benton <[EMAIL PROTECTED]> wrote:
>
> Gnome-vfs checks for sys/inotify.h (which comes from glibc) and
> linux/inotify.h (which comes from the kernel). If we do it the way
> you're suggesting it would find sys/inotify.h but not linux/inotify.h so
> it may work or it may not. I thi
Andrew Benton wrote these words on 04/10/06 15:19 CST:
> It was good enough for LFS-6
> http://archive.linuxfromscratch.org/lfs-museum/6.0/LFS-BOOK-6.0-HTML/chapter05/kernel-headers.html
>
>
> In chapter 6 glibc was configured --with-headers=/tools/glibc-kernheaders
Thanks for the research An
Jeremy Herbison wrote:
Well, if you say so... I know it was in unstable at least, shortly after
kernel 2.6 was introduced.
Either way, can you see any technical reasons why that would not make a good
stop-gap solution for inotify etc. support?
It was good enough for LFS-6
http://archive.linux
On Mon, 2006-04-10 at 13:46 -0600, Jeremy Herbison wrote:
> > 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/gl
On Mon, Apr 10, 2006 at 01:46:49PM -0600, Jeremy Herbison wrote:
>
> Either way, can you see any technical reasons why that would not make a good
> stop-gap solution for inotify etc. support?
Yes. We can just add the inotify header and call it a day without
changing the method of building.
--
A
>
> 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.
>
> W
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 were you
> On Mon, Apr 10, 2006 at 12:34:21PM -0600, Jeremy Herbison wrote:
> >
> > What about using kernel headers for building glibc, and linux-libc-
> headers
> > for userspace, like we used to do? My understanding is that the glibc
> > developers are still using/recommending this anyhow. Would certainly
On Mon, Apr 10, 2006 at 12:34:21PM -0600, Jeremy Herbison wrote:
>
> What about using kernel headers for building glibc, and linux-libc-headers
> for userspace, like we used to do? My understanding is that the glibc
> developers are still using/recommending this anyhow. Would certainly be the
> ea
> 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 ha
27 matches
Mail list logo
