-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bryan Kadzban wrote:
Bruce Dubbs wrote:
Bruce Dubbs wrote:
Chris Staub wrote:
On 11/19/2009 08:30 PM, Bruce Dubbs wrote:
Chris Staub wrote:
But there are the .install files in every subdir, not just in the
linux dir. I use:
find dest/include
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
ABCD wrote:
You could also do:
find dest/include -name '.*install*' -delete
Disregard that, I didn't read all my mail before replying...
- --
ABCD
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.13 (GNU/Linux)
Comment: Using GnuPG with
Bruce Dubbs wrote:
Chris Staub wrote:
On 11/19/2009 07:51 PM, Bruce Dubbs wrote:
The problem is that find is returning a full path. That will copy all
files to /usr/include. You would have to parse each line of the find
output to remove the path before the current directory.
We now do:
On Fri, Nov 20, 2009 at 12:22 AM, Matthew Burgess
matt...@linuxfromscratch.org wrote:
Bruce Dubbs wrote:
Chris Staub wrote:
On 11/19/2009 07:51 PM, Bruce Dubbs wrote:
The problem is that find is returning a full path. That will copy all
files to /usr/include. You would have to parse
On Fri, 20 Nov 2009 02:10:46 -0800, Nathan Coulson conat...@gmail.com wrote:
It may be dangerous for us to recommend deleting files recursively. In
the event of a typo, it could cause a bit of damage.
Well, in the event of a typo, all the user would have to do is to untar the
kernel source
Matthew Burgess wrote:
Thanks guys, removing them at the source is obviously correct. I'd
prefer this variant, though:
find dest/include -name .install --or -name ..install.cmd -delete
I believe that '-delete' is the recommended/race-free way of removing
files found by find(1), though
Hi,
As mentioned at [0], we end up with a bunch of .install and
..install.cmd files under /usr/src/linux and its subdirectories. The
trivial command to clean these up post-install has already been added to
at least the ppc64 version of CLFS [1], so I see no reason why we
couldn't just merge
Matthew Burgess wrote:
Hi,
As mentioned at [0], we end up with a bunch of .install and
..install.cmd files under /usr/src/linux and its subdirectories. The
trivial command to clean these up post-install has already been added to
at least the ppc64 version of CLFS [1], so I see no reason
On 11/19/2009 07:51 PM, Bruce Dubbs wrote:
The problem is that find is returning a full path. That will copy all
files to /usr/include. You would have to parse each line of the find
output to remove the path before the current directory.
We now do:
make INSTALL_HDR_PATH=dest
Chris Staub wrote:
On 11/19/2009 07:51 PM, Bruce Dubbs wrote:
The problem is that find is returning a full path. That will copy all
files to /usr/include. You would have to parse each line of the find
output to remove the path before the current directory.
We now do:
make
On 11/19/2009 08:30 PM, Bruce Dubbs wrote:
Chris Staub wrote:
But there are the .install files in every subdir, not just in the
linux dir. I use:
find dest/include -name .install -or -name ..install.cmd | xargs rm -fv
Ahh. I didn't realize they were in multiple directories.
find
Chris Staub wrote:
On 11/19/2009 08:30 PM, Bruce Dubbs wrote:
Chris Staub wrote:
But there are the .install files in every subdir, not just in the
linux dir. I use:
find dest/include -name .install -or -name ..install.cmd | xargs rm -fv
Ahh. I didn't realize they were in multiple
Chris Staub wrote:
On 11/19/2009 08:30 PM, Bruce Dubbs wrote:
find dest/include -name .install -or -name ..install.cmd -exec rm
-v '{}' \;
Not quite - the -exec only works on the last option before it...or
something, I'm not quite sure exactly how to describe it technically,
but in this
Bruce Dubbs wrote:
Chris Staub wrote:
On 11/19/2009 08:30 PM, Bruce Dubbs wrote:
Chris Staub wrote:
But there are the .install files in every subdir, not just in the
linux dir. I use:
find dest/include -name .install -or -name ..install.cmd | xargs rm -fv
Ahh. I didn't realize they were
Bruce Dubbs wrote:
Bruce Dubbs wrote:
Chris Staub wrote:
On 11/19/2009 08:30 PM, Bruce Dubbs wrote:
Chris Staub wrote:
But there are the .install files in every subdir, not just in the
linux dir. I use:
find dest/include -name .install -or -name ..install.cmd | xargs rm -fv
Ahh. I didn't
sed -i s/# include asm\/page.h/#/ /ext/IPC/SysV/SysV.xs
This was previously discussed at
http://archive.linuxfromscratch.org/mail-archives/lfs-dev/2008-April/061291.html
but I have seen no further bugreports or discusson on this topic since then.
I have compiled a full LFS SVN system against
On 3/2/07, Dan Nicholson [EMAIL PROTECTED] wrote:
On 3/2/07, Matthew Burgess [EMAIL PROTECTED] wrote:
On Friday 02 March 2007 22:50, Dan Nicholson wrote:
Thanks for the info, Arden. That's good enough for me to ensure that
the scsi headers only get installed by glibc. Patch attached.
is this necessary? Aren't the Glibc headers
copied over the kernel headers during the Glibc installation?
--
Randy
rmlscsi: [bogomips 1003.28] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3]
[GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686]
17:14:00 up 14 days, 15:13, 1 user, load average: 0.27
in the spec file:
Just out of curiosity, why is this necessary? Aren't the Glibc headers
copied over the kernel headers during the Glibc installation?
Yeah, it's not stricly necessary in the context of the book. This is
more a preference not to have conflicting files. I think we talked
about doing
On 3/2/07, Arden [EMAIL PROTECTED] wrote:
On Feb 14, 2007, at 12:34 PM, Dan Nicholson wrote:
On 2/14/07, Arden [EMAIL PROTECTED] wrote:
also glibc-2.5 wants to replace the linux-header file
/usr/include/scsi/sg.h with it's own.
Should we be addressing this? I noticed that in Fedora they
://www.diy-linux.org/x86-reference-build/chroot.html#c-linux-kernel-headers
It's really no different than man-pages, though.
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
On Wednesday 14 February 2007 20:34, Dan Nicholson wrote:
On 2/14/07, Arden [EMAIL PROTECTED] wrote:
also glibc-2.5 wants to replace the linux-header file
/usr/include/scsi/sg.h with it's own.
Should we be addressing this?
Yes.
I noticed that in Fedora they remove the
scsi directory
Ken Moffat wrote:
More on-topic for this list, x86 now has two reports of successful
builds. Maybe LFS should reclaim its 'bleeding edge' position and
switch to the 2.6.18 headers as soon as the new kernel is out, then
let people here and in BLFS find out if anything is broken in use ?
. Does this mean that his stance is that
he will not add functionality to the kernel headers, and it is the
programs trying to use these headers that are broken?
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above
the second sentence means. Does this mean that his stance is that
he will not add functionality to the kernel headers, and it is the
programs trying to use these headers that are broken?
--
Dan
This means userspace still will be broken until we submit patches to the
upstream maintainers
the headers_install kernel
headers it's because:
1) headers_install didn't install a header that provides a public API or
2) the package is (ab)using an internal kernel header, that by pure
historical accident happened to be available until recently.
In the case of 1) we need to submit patches
Jim Gifford wrote:
Matt, I agree, but, what I think is wrong is the idealism that David
Woodhouse has on this, he doesn't care if something breaks. A really
good example here is iptables. How would you suggest handling that can
of worms.
As per my proposal above, patch iptables to fix the
not just him, it's Linus. I know you've read the
headers threads on lkml (probably way more than I have), so you know
that Linus wants nothing to do with helping out packages that use the
kernel headers in a broken way. Here's a quick summary:
http://kerneltrap.org/node/6536
So, you're probably
like cdrtools, xine, KDE, K3B
postgresql, samba etc.pp...
... Next major change will be the kernel headers.
That's another discussion, though.
I think we should start it! IMHO the -rc7 is what we can expect in 2.6.18.
With the -rc7, I actually built a system on my laptop (500MHz-PIII yawn
Thomas Trepl wrote:
Be carefull with the headers_install target. It cleans the destination first
and than installs the headers into. Previously installed headers got lost.
Well, there's a proposal to change that at
http://www.ussg.iu.edu/hypermail/linux/kernel/0609.2/0351.html:
I'd like to
On 9/18/06, Thomas Trepl [EMAIL PROTECTED] wrote:
... Next major change will be the kernel headers.
That's another discussion, though.
I think we should start it! IMHO the -rc7 is what we can expect in 2.6.18.
With the -rc7, I actually built a system on my laptop (500MHz-PIII yawn!). On
my
On Monday 18 September 2006 23:21, Matthew Burgess wrote:
Thomas Trepl wrote:
Be carefull with the headers_install target. It cleans the destination
first and than installs the headers into. Previously installed headers
got lost.
Well, there's a proposal to change that at
On Mon, Sep 18, 2006 at 10:05:08PM +0200, Thomas Trepl wrote:
... Next major change will be the kernel headers.
That's another discussion, though.
I think we should start it! IMHO the -rc7 is what we can expect in 2.6.18.
With the -rc7, I actually built a system on my laptop (500MHz-PIII
Ken Moffat wrote:
On Mon, Sep 18, 2006 at 10:05:08PM +0200, Thomas Trepl wrote:
... Next major change will be the kernel headers.
That's another discussion, though.
I think we should start it! IMHO the -rc7 is what we can expect in 2.6.18.
With the -rc7, I actually built
On Mon, Sep 18, 2006 at 07:13:27PM -0400, Joe Ciccone wrote:
I tested the in kernel headers on mips/alpha/sparc. There were a lot of
problems. silo and aboot didn't want to build right. The build had so
many errors in it, on all 3 of the archs, That I just walked away. I did
have a succesful
them with the clfs script. I'd prefer if we can use headers_install
straight from the kernel, but we'll see what can be done about that. I
tend to think that we should fix the broken packages rather than
adding compatibility helpers into the kernel headers. Maybe it'll be
too much pain, though
steve crosby wrote:
On 5/4/06, Jim Gifford [EMAIL PROTECTED] wrote:
Steve,
I just added a headers_list script that will look at the sources and
pull all the headers and put them into a report. Let's run that and
compare what I have in the script now to see what's missing.
On 5/4/06, Jim Gifford [EMAIL PROTECTED] wrote:
I probably need to document that a little better. Basically you untar
your program and tell it ./headers_list iptables-1.3.5 and it creates a
report of all the headers needed for a build.
That makes more sense ;)
resulting asm-headers and
On 5/4/06, Jim Gifford [EMAIL PROTECTED] wrote:
I probably need to document that a little better. Basically you untar
your program and tell it ./headers_list iptables-1.3.5 and it creates a
report of all the headers needed for a build.
also below are results for ulog, a companion program to
On 5/4/06, Jim Gifford [EMAIL PROTECTED] wrote:
steve crosby wrote:
My intent was to identify that one of the options provided in the
thread (Jim's work with the linux headers) has problems, as it's
currently not working with certain applications outside of LFS.
snip
I think I was able
steve crosby wrote:
On 5/4/06, Jim Gifford [EMAIL PROTECTED] wrote:
steve crosby wrote:
My intent was to identify that one of the options provided in the
thread (Jim's work with the linux headers) has problems, as it's
currently not working with certain applications outside of LFS.
snip
steve crosby wrote:
On 5/4/06, Jim Gifford [EMAIL PROTECTED] wrote:
steve crosby wrote:
My intent was to identify that one of the options provided in the
thread (Jim's work with the linux headers) has problems, as it's
currently not working with certain applications outside of LFS.
snip
On 5/4/06, Jim Gifford [EMAIL PROTECTED] wrote:
Steve, I think I got it covered in the 00.52, I'll be posting it shortly.
still no joy
linux/dccp.h missing - I added that, and then this occurs
extensions/libipt_connmark.c: In function 'init':
extensions/libipt_connmark.c:52: error:
Ok, got those changes in. Thanx for the reports Steve, this is what I need.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
On 5/4/06, Jim Gifford [EMAIL PROTECTED] wrote:
Ok, got those changes in. Thanx for the reports Steve, this is what I need.
no worries - with those changes (dccp.h, netfilter.h) iptables (and
ulog) compile fine. Diff attached for headers script for reference
diff -Naur headers.sh.orig
steve crosby wrote:
On 5/4/06, Jim Gifford [EMAIL PROTECTED] wrote:
Ok, got those changes in. Thanx for the reports Steve, this is what I
need.
no worries - with those changes (dccp.h, netfilter.h) iptables (and
ulog) compile fine. Diff attached for headers script for reference
diff -Naur
Steve,
I just added a headers_list script that will look at the sources and
pull all the headers and put them into a report. Let's run that and
compare what I have in the script now to see what's missing.
http://ftp.jg555.com/headers/headers_list
--
On 5/4/06, Jim Gifford [EMAIL PROTECTED] wrote:
Steve,
I just added a headers_list script that will look at the sources and
pull all the headers and put them into a report. Let's run that and
compare what I have in the script now to see what's missing.
On 4/29/06, Jim Gifford [EMAIL PROTECTED] wrote:
What would be nice is if we could go back to the 2.4 does things,
they we wouldn't have these issues. I've contacted David, to see if we
could collaborate on the effort, but I haven't heard anything yet. From
what I've read in that thread,
Ioan Ionita wrote:
Probably not gonna be merged. Linus doesn't plan on making any header
useable by userspace. I don't quite understand his whole point. It
seems like he's allergic or something, thinking that if the headers
are cleaned up, apps will start using them. Anyway, he doesn't seem to
Ioan Ionita wrote:
Linus doesn't plan on making any header useable by userspace.
Not entirely true; from what I was reading in the archives, Linus
doesn't mind making the kernel headers usable by glibc. But he
absolutely does not want random userspace programs using them, because
On 4/30/06, Bryan Kadzban [EMAIL PROTECTED] wrote:
(That's because fcntl.h is glibc's interface to the rest of userspace.
It needs to define that interface well enough that random userspace
programs will almost all work. In the same vein, though, the Linux
kernel needs to define its interface
Hello World!
Have you guys been reading
http://www.uwsg.iu.edu/hypermail/linux/kernel/0604.3/1042.html ? I think
this looks really good. If the kernel headers are cleaned up with lots
of stuff moved inside #ifdef __KERNEL__s it will make it much easier for
Jims script to produce usable
[EMAIL PROTECTED] wrote:
Hello World!
Have you guys been reading
http://www.uwsg.iu.edu/hypermail/linux/kernel/0604.3/1042.html ? I think
this looks really good.
Yep, I've been trying to follow the various recent discussions related to
the kernel headers.
If the kernel headers
Andrew Benton wrote:
Hello World!
Have you guys been reading
http://www.uwsg.iu.edu/hypermail/linux/kernel/0604.3/1042.html ? I
think this looks really good. If the kernel headers are cleaned up
with lots of stuff moved inside #ifdef __KERNEL__s it will make it
much easier for Jims script
DJ Lucas wrote:
Jim Gifford wrote:
I don't see any of these references in sys/types.h, or am I missing
something.
Glibc-2.3.6. This may not be an issue at all, see below. Will let you
know tomorrow if I have the time to complete xorg.
Hello, just wanted to reply back so not to leave
Are there significant disadvantages to using raw headers for glibc, and fedora
headers for userland, like the nptl hint did?
robert
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Matthew Burgess wrote:
Alexander E. Patrakov wrote:
BLFS is not the right place to work around libc bugs.
Agreed. If someone could cook up a patch for glibc-2.3.6 I'd appreciate
it.
DJ Lucas wrote:
Ran into difficulties tonight. Need to protect against kernel types
that conflict with glibc in linux/types.h.
From llh:
#include sys/types.h
#include linux/posix_types.h
#include asm/types.h
#ifndef __KERNEL_STRICT_NAMES
typedef __u32 __kernel_dev_t;
#if
DJ Lucas wrote:
Ran into difficulties tonight. Need to protect against kernel types
that conflict with glibc in linux/types.h.
I'm not sure what you're trying say in this post. It would help if you
specified the actual problem you are having.
The quick solution for xorg-server was to
Jim Gifford wrote:
I don't see any of these references in sys/types.h, or am I missing something.
Glibc-2.3.6. This may not be an issue at all, see below. Will let you
know tomorrow if I have the time to complete xorg.
---
Greg Schafer wrote:
I'm not sure what
DJ Lucas wrote:
Sorry for the noise. Thanks for taking a look. Oh, I also forgot about
the original problem with sys/kd.h. Thanks for the reminder. Should
this be fixed in LFS if continuing with glibc-2.3.6? Xorg is the only
known (to me) issue and it's worked around in BLFS.
BLFS is
Alexander E. Patrakov wrote:
BLFS is not the right place to work around libc bugs.
Agreed. If someone could cook up a patch for glibc-2.3.6 I'd appreciate it.
Thanks,
Matt.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See
Jürg Billeter wrote:
I know that it's far from ideal but the only ideal way I see would be to
extensively add __KERNEL__ ifdefs to the linux headers upstream so that
the script could recognize automatically which headers are
kernel-internal. Unfortunately this probably won't happen in the
DJ Lucas wrote:
Don't do that. Do it from the toplevel. There is one instance in
linux/errno.h for asm-generic/errno.h.
okay..scratch that completely...
Kill asm-generic with this snipit:
## Flatten asm-generic headers
# first unifdef all the _ASM_GERNERIC_*_H #ifndef's
cd asm-generic
Jürg Billeter wrote:
Yes, as I've written before, iproute2 is one of the problematic
packages. Besides fixing the includes[1] you need to remove the local
copy of the not sanitized kernel headers, i.e. rm -r include/linux[2]
Jürg
[1]
http://www.paldo.org/paldo/sources/iproute2/iproute2
On Son, 2006-03-19 at 12:28 -0600, DJ Lucas wrote:
Jürg Billeter wrote:
Yes, as I've written before, iproute2 is one of the problematic
packages. Besides fixing the includes[1] you need to remove the local
copy of the not sanitized kernel headers, i.e. rm -r include/linux[2]
I'm using
sanitized kernel headers, they are
specific to glibc and as we've just found out, it only works with 2.4
even.
Well, specific to what paldo uses, but the package base is large enough
to catch most, if not all, of what LFS will use too. For this
particular situation, I think it's still best (LFS
Andrew Benton wrote:
Jim Gifford wrote:
Andrew Benton wrote:
Sysklog-1.4.1 seems to have a problem with asm/atomic.h
If it includes asm/processor.h then the sysklog build errors out like
this
andy:/sources/sysklogd-1.4.1$ make
gcc -O3 -DSYSV -fomit-frame-pointer -Wall
DJ Lucas wrote:
Jan 10, 1998 to overcome a problem with linux-2.1.18.
Whoops. Wrong long entry! Let me correct that Mar 31, 2004 to correct
a problem with 2.4 and 2.6. May still be unneeded.
-- DJ Lucas
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ:
I've actually taken the scripts a bit further. Building GLIBC and
GCC from the raw kernel headers and only using the sanitized stuff for
everything else. On a few of the lists I have seen this done with
success and found out that this is the recommended build method for
GLIBC, still
On Sun, Mar 19, 2006 at 02:10:16PM -0800, Jim Gifford wrote:
I've actually taken the scripts a bit further. Building GLIBC and
GCC from the raw kernel headers and only using the sanitized stuff for
everything else. On a few of the lists I have seen this done with
success and found out
Archaic writes:
Wasn't it the glibc devs who screamed the loudest about headers? Have
they changed their stance or is my memory getting fuzzy in my old age?
:)
--
Archaic
In 2003, Roland actually said glibc should be built with the raw headers.
The thing he's not for is glibc
On Sun, Mar 19, 2006 at 07:24:13PM -0800, Jim Gifford wrote:
In 2003, Roland actually said glibc should be built with the raw headers.
The thing he's not for is glibc maintaining the headers. The original email
was around July when Greg asked him about the headers.
Thanks for the reply,
On Sam, 2006-03-18 at 08:56 +0500, Alexander E. Patrakov wrote:
Jürg Billeter wrote:
- asterisk: Uses linux/compiler.h, include line could just be removed as
linux/ixjuser.h doesn't need the compiler.h defines due to the seds we
apply to the headers
Then better make linux/compiler.h an
DJ Lucas wrote:
for FILE in `echo
linux/{acct.h,quota.h,resource.h,socket.h,stat.h,time.h,timex.h,un.h,wait.h}`
Er, hang on here -- why are the echo and the backquotes in there? (I
should note that they're in Jürg's script as well.) They gain nothing,
and waste at least one process. (I
Bryan Kadzban wrote:
DJ Lucas wrote:
for FILE in `echo
linux/{acct.h,quota.h,resource.h,socket.h,stat.h,time.h,timex.h,un.h,wait.h}`
Er, hang on here -- why are the echo and the backquotes in there? (I
should note that they're in Jürg's script as well.) They gain nothing,
and waste at
On Sat, 18 Mar 2006, J�rg Billeter wrote:
On Sam, 2006-03-18 at 08:56 +0500, Alexander E. Patrakov wrote:
Then better make linux/compiler.h an empty file.
If you want to go for best compatibility, sure; I currently aim to get
the header set as clean as possible, i.e. applications including
On Sam, 2006-03-18 at 16:10 +, Ken Moffat wrote:
On Sat, 18 Mar 2006, Jrg Billeter wrote:
On Sam, 2006-03-18 at 08:56 +0500, Alexander E. Patrakov wrote:
Then better make linux/compiler.h an empty file.
If you want to go for best compatibility, sure; I currently aim to get
the
On Fre, 2006-03-17 at 23:37 -0600, DJ Lucas wrote:
Using the above notes, I've added the following to Jürg's version of the
script so to create the 'compatibility' headers. Of course these
could be created once and be copied too...just figured I'd add to the
script so no local files must
On Sam, 2006-03-18 at 08:24 -0500, Bryan Kadzban wrote:
DJ Lucas wrote:
for FILE in `echo
linux/{acct.h,quota.h,resource.h,socket.h,stat.h,time.h,timex.h,un.h,wait.h}`
Er, hang on here -- why are the echo and the backquotes in there? (I
should note that they're in Jürg's script as
Jürg Billeter wrote:
On Sam, 2006-03-18 at 08:56 +0500, Alexander E. Patrakov wrote:
Jürg Billeter wrote:
- asterisk: Uses linux/compiler.h, include line could just be removed as
linux/ixjuser.h doesn't need the compiler.h defines due to the seds we
apply to the headers
Then better make
Jürg Billeter wrote:
I've also removed the asm-generic
flattening as I don't see any benefit in doing that but maybe there is,
then please explain.
Not really any benifit other than it was done with previous LLH. The
one minor benefit is one less directory. That's it. :-) It adds about
Jürg Billeter wrote:
It's right that they gain nothing in the for loops. I've added the
backticks to the REMOVE_HEADERS lines on purpose, though, as the
shell doesn't expand braces when defining variables but probably
there is a better way to get expanded variables, don't know.
Hmm... You
On Sam, 2006-03-18 at 19:22 +, Ken Moffat wrote:
On Sat, 18 Mar 2006, Jrg Billeter wrote:
Could you post the error message? What exact header set did you use?
Just removing linux/compiler.h without removal of compiler.h references
and the correct seds for __user etc. is likely to
Jürg Billeter wrote:
I've integrated most of your changes and put it online at
http://www.paldo.org/headers/linux-glibc-headers-20060318
I changed the error messages in linux/compiler.h and linux/config.h to
warnings to really be a compatibility header.
Thanks Jürg. With that script I made the
DJ Lucas wrote:
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.
I have an idea about this too. This may not be portable because of the
math, not sure:
cd asm-${arch}
Don't do
/linux/netlink.h:4:48: error: linux/socket.h: No such file or
directory
make[1]: *** [ll_map.o] Error 1
Yes, as I've written before, iproute2 is one of the problematic
packages. Besides fixing the includes[1] you need to remove the local
copy of the not sanitized kernel headers, i.e. rm -r include
doesn't need the compiler.h defines due to the seds we
apply to the headers
I've also run a script to find used kernel headers over the sources of
the 800 packages (except kernel and headers packages). You can find the
results on http://www.paldo.org/headers/
* headers-list: Sorted list of all
Jürg Billeter wrote:
I've also run a script to find used kernel headers over the sources of
the 800 packages (except kernel and headers packages). You can find the
results on http://www.paldo.org/headers/
Wow. Again, excellent work.
* headers-list: Sorted list of all found header
On Sam, 2006-03-18 at 08:50 +1100, Greg Schafer wrote:
Jürg Billeter wrote:
* headers-list: Sorted list of all found header references
* headers-xref: Header list cross-referenced to the package names
(useful to exclude header references of kernel module source code that's
unfortunately
Jürg Billeter wrote:
- asterisk: Uses linux/compiler.h, include line could just be removed as
linux/ixjuser.h doesn't need the compiler.h defines due to the seds we
apply to the headers
Then better make linux/compiler.h an empty file.
--
Alexander E. Patrakov
--
I'd add to the
script so no local files must be kept around. Also, as Alexander
mentioned in the other reply to this message, it might be best to just
empty linux/compiler.h, as is done with llh instead of erroring out.
-- DJ Lucas
# Replace removed kernel headers that have a glibc equivelent
not, as I haven't found major parts missing in
glibc' equivalent to those kernel headers. The glibc headers are
organized a bit differently, though, some definitions are guarded by
defines from features.h which may require _..._SOURCE defines during
compilation - as has happened with rp-pppoe.
wind
fails this criteria. Also note there are many kernel headers
simply not shipped with LLH.
I should have been a bit more specific: I wasn't filtering out headers
that aren't in LLH (and I wasn't going to compile dosemu either). I
was, however, only checking the stuff in include/linux and
include/asm
Bryan Kadzban wrote:
gccver=`gcc -dumpversion`
Oops, that doesn't need to be there anymore...
(I attempted at one point to add -nostdinc to the gcc command line, so I
needed to add the system header location
(/usr/lib/gcc/$MACHTYPE/$gccver/include) to the search path. That
seemed to fail, and
On Tue, Mar 14, 2006 at 02:10:27PM +0100, J?rg Billeter wrote:
a=$(echo -ne '\001')
b=$(echo -ne '\002')
These can probably be simplified to:
a=$'\001'
b=$'\002'
pushd $KERNEL_PATH/include
I don't think you need to pushd at the start and then popd at the end of
the script. The script's
Jürg Billeter wrote:
Yes, LLH fails that criteria and it ships with a lot of kernel-only
stuff. Based on Jim's script I've written an extended version which
removes a lot of headers that shouldn't be part of the linux glibc
header set, AFAICT.
Cool. But one has to ask how you arrived at the
Thanks for your comments.
On Die, 2006-03-14 at 13:05 -0500, Bryan Kadzban wrote:
On Tue, Mar 14, 2006 at 02:10:27PM +0100, J?rg Billeter wrote:
a=$(echo -ne '\001')
b=$(echo -ne '\002')
These can probably be simplified to:
a=$'\001'
b=$'\002'
Didn't know that, changed.
pushd
On Die, 2006-03-14 at 14:10 +0100, Jürg Billeter wrote:
* Verify headers with real applications
Will do a full distro (800 packages) recompilation with these headers
sometime this week and fix headers resp. applications as necessary
Short preliminary report after rebuilding the base system
1 - 100 of 176 matches
Mail list logo
