On 03/02/2014 10:13 AM, William Harrington wrote:
> On Mar 2, 2014, at 8:22 AM, thomas wrote:
>
>> If I remember right, at least in previous versions of the kernel
>> sources
>> the target directory had been cleared before the headers were written.
>> That would be
On Mar 2, 2014, at 8:22 AM, thomas wrote:
> If I remember right, at least in previous versions of the kernel
> sources
> the target directory had been cleared before the headers were written.
> That would be no good for the /tools/include dir but meaningless for
> the
> n
On 03/02/2014 09:22 AM, thomas wrote:
> Am Sonntag, den 02.03.2014, 08:36 -0500 schrieb baho utot:
>> Why is the installation of the headers in the book like this
>>
>> make INSTALL_HDR_PATH=dest headers_install
>> cp -rv dest/include/* /tools/include
>>
>>
Am Sonntag, den 02.03.2014, 08:36 -0500 schrieb baho utot:
> Why is the installation of the headers in the book like this
>
> make INSTALL_HDR_PATH=dest headers_install
> cp -rv dest/include/* /tools/include
>
> instead of
>
> make INSTALL_HDR_PATH=/tools/include he
Why is the installation of the headers in the book like this
make INSTALL_HDR_PATH=dest headers_install
cp -rv dest/include/* /tools/include
instead of
make INSTALL_HDR_PATH=/tools/include headers_install
??
Would the latter be "just the same" or am I missing something here?
- Mail original -
> De: "Bruce Dubbs"
> À: "LFS Developers Mailinglist"
> Envoyé: Vendredi 25 Janvier 2013 17:55:21
> Objet: Re: [lfs-dev] procps-ng install headers to /include/proc/ instead of
> /usr/include/proc/
>
> Armin K. wrote:
> >
Armin K. wrote:
> On 01/25/2013 12:19 PM, xinglp wrote:
>> Is that normal?
>>
>
> I wonder why they didn't use my configure line. It should be ./configure
> --prefix=/usr --exec-prefix=
>
> And if you don't prefer .la files in /lib, add --libdir=/usr/lib and
> move so.num* to lib and make a symlink
xinglp wrote:
> and this,
> ./configure --prefix=\
> --mandir=/usr/share/man \
> --docdir=/usr/share/doc/$PROGRAM \
> --disable-skill \
> --disable-kill
>
> what is $PROGRAM ?
My fault. I copied
On 01/25/2013 12:19 PM, xinglp wrote:
> Is that normal?
>
I wonder why they didn't use my configure line. It should be ./configure
--prefix=/usr --exec-prefix=
And if you don't prefer .la files in /lib, add --libdir=/usr/lib and
move so.num* to lib and make a symlink ...
--
http://linuxfromscr
to agree, but people who have built a recent LFS will
> probably not notice that change to the host requirements - perhaps
> we need to swallow our pride and point out that it is our own users
> who might need to do this ?
I decided to add the instructions to Chapter 5 glibc. For most
On Mon, Aug 27, 2012 at 09:48:41AM -0500, Bruce Dubbs wrote:
>
> I think we have corner case here. The only system that is a problem is
> 7.1 without libtirpc being installed (or someone who didn't follow the
> book). Now that I think of it, we could add to the host system
> requirements a c
-headers.tar.bz2 -C /usr/include
>> fi
>>
>
> Almost. For 7.1, we didn't install them. We fixed that a little
> while later, so my own 7.1 installs include them. For 7.2 we _do_
> install them, at least if people follow all the instructions. The
> switch
On Mon, 27 Aug 2012 05:20:39 +0100, Jasmine Iwanek wrote:
> I'll have a poke at building glibc with no host headers shortly to see
> what other headers get pulled in, if nothing else it'll keep Greg quiet
Fat chance of that :-)
Anyway, my immediate concerns have been allayed
On 2012-08-27 05:00, Ken Moffat wrote:
> On Mon, Aug 27, 2012 at 03:46:00AM +0100, Jasmine Iwanek wrote:
>>
>> As I've stated several times now, we should *not* be pulling host
>> headers into glibc.
>>
> You haven't explained why you didn't install
l suffice.
I'll have a poke at building glibc with no host headers shortly to see
what other headers get pulled in, if nothing else it'll keep Greg quiet,
especially if we can either prove that the build is clean or prove that
any "contamination" in ch5 doesn't actually m
didn't install them. We fixed that a little
while later, so my own 7.1 installs include them. For 7.2 we _do_
install them, at least if people follow all the instructions. The
switch is a cleaner way of doing it, but it installs a bit more
(.x pascal headers - just like in the old version
Ken Moffat wrote:
> On Mon, Aug 27, 2012 at 03:46:00AM +0100, Jasmine Iwanek wrote:
>>
>> As I've stated several times now, we should *not* be pulling host
>> headers into glibc.
>>
> You haven't explained why you didn't install the headers on youur
&
On Mon, Aug 27, 2012 at 03:46:00AM +0100, Jasmine Iwanek wrote:
>
> As I've stated several times now, we should *not* be pulling host
> headers into glibc.
>
You haven't explained why you didn't install the headers on youur
first build. In page 6.9 we say
Install
pcgen the binary (since it no longer depends on
> anything).
>
Dunno - with that patch, which I still think is not the sort of
thing we want to maintain, chapter 5 built ok without rpc headers,
and chapter 6 has just installed. For chapter 6, the new configure
option appears to be working
Jasmine Iwanek wrote:
> On 2012-08-27 04:00, Bruce Dubbs wrote:
>>> As I've stated several times now, we should *not* be pulling host
>>> headers into glibc.
>>
>> I don't think we are. We are building cross-rpcgen as a tool to run
>> on
>&g
On 2012-08-27 04:00, Bruce Dubbs wrote:
>> I thought we'd already concluded that?
>
> We were revisiting other options.
>
Fair enough
>> As I've stated several times now, we should *not* be pulling host
>> headers into glibc.
>
> I don't think we
we'd already concluded that?
We were revisiting other options.
> As I've stated several times now, we should *not* be pulling host
> headers into glibc.
I don't think we are. We are building cross-rpcgen as a tool to run on
the host, but it's never put on the target syst
gt;
>> -- Bruce
>
> I thought we'd already concluded that?
>
> As I've stated several times now, we should *not* be pulling host
> headers into glibc.
Except that we're *not*, and the glibc headers are *not* necessarily the
right ones to be using. (I do
ed a note to install
> the rpcnis-headers.tar.bz2 tarball as a part of Chapter 5 glibc.
>
> That's not something I want to do. Perhaps the workaround of the sed
> for Chapter 5 is the way to go.
>
>-- Bruce
I thought we'd already concluded that?
As I've state
Starting a new thread.
Bryan Kadzban wrote:> Bruce Dubbs wrote:
>> Try this as the lfs user:
>>
>> tar -xf glibc-2.16.0.tar.xz
>> cd glibc-2.16.0
>>
>> sed -i 's/ -lgcc_s//' Makeconfig
>> sed -i 's||"rpc/types.h"|' sunrpc/rpc_clntout.c
>>
>> mkdir -v ../glibc-build
>> cd ../glibc-build
William Harrington wrote:
>
> On Aug 20, 2012, at 11:56 AM, Ken Moffat wrote:
>
>> When I was looking at fedora, I noticed that they use another
>> configure switch: --enable-obsolete-rpc. Adding that installs the
>> rpc and rpcsvc headers (as well as the rpcsvc pas
On Aug 20, 2012, at 11:56 AM, Ken Moffat wrote:
> When I was looking at fedora, I noticed that they use another
> configure switch: --enable-obsolete-rpc. Adding that installs the
> rpc and rpcsvc headers (as well as the rpcsvc pascal .x files which
> glibc used to install [ I look
On 08/20/2012 06:56 PM, Ken Moffat wrote:
> When I was looking at fedora, I noticed that they use another
> configure switch: --enable-obsolete-rpc. Adding that installs the
> rpc and rpcsvc headers (as well as the rpcsvc pascal .x files which
> glibc used to install [ I look
When I was looking at fedora, I noticed that they use another
configure switch: --enable-obsolete-rpc. Adding that installs the
rpc and rpcsvc headers (as well as the rpcsvc pascal .x files which
glibc used to install [ I looked at 2.12.2 ].
Does that seem a worthwhile change to make ? (not
Hello World!
I recently tried compiling using the current stable kernel headers
(2.6.38) and udev failed to compile like so:
CC extras/v4l_id/v4l_id.o
extras/v4l_id/v4l_id.c:31:28: fatal error: linux/videodev.h: No such file or
directory
compilation terminated.
make[2]: *** [extras/v4l_id
William Immendorf wrote:
> On Tue, Jan 11, 2011 at 2:35 PM, Bruce Dubbs wrote:
>> Yes. The kernel headers include definitions for the kernel only. Don't
>> use the kernel headers for applications or utilities.
> Unless you want to use the kernel for direct hardwa
On Tue, Jan 11, 2011 at 2:35 PM, Bruce Dubbs wrote:
> Yes. The kernel headers include definitions for the kernel only. Don't
> use the kernel headers for applications or utilities.
Unless you want to use the kernel for direct hardware access or
graphics accleration.
--
William Im
Ok, thank you!
Best regards
Am Dienstag, den 11.01.2011, 14:35 -0600 schrieb Bruce Dubbs:
> Yes. The kernel headers include definitions for the kernel only. Don't
> use the kernel headers for applications or utilities.
>
>-- Bruce
--
http://linuxfromscratch.org/mai
Sebastian Plotz wrote:
> Is there a difference between using the header files from the kernel
> (for example /usr/include/linux/inotify.h) or the header files from
> glibc (/usr/include/sys/inotify.h)?
Yes. The kernel headers include definitions for the kernel only. Don't
Hello,
this doesn't directly belongs to LFS but maybe somebody can answer my
question.
Is there a difference between using the header files from the kernel
(for example /usr/include/linux/inotify.h) or the header files from
glibc (/usr/include/sys/inotify.h)?
Sebastian
--
http://linuxfromscra
-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 wit
-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" di
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),
On Fri, 20 Nov 2009 02:10:46 -0800, Nathan Coulson 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 tarball again, as w
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
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.
>>>
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.c
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.
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 i
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 i
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.
>
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:
>>
>> ma
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 h
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 r
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 t
Hi!
Which include/scsi/*.h headers are used by LFS? It seems that the
ones from glibc. If so, mentioning them in Sec. 6.7.2 "Contents of
Linux API Headers" is misleading, I think.
If, however, they can be installed in Linux Headers sections and
then overwritten in Glibc sections (C
2009/6/16 Konrad Mosoń
>
> Hi.
>
> I creating now LFS, and i was on page:
> 5.6. Linux-2.6.27.4 API Headers
> from
> LFS-BOOK-6.4.
>
> I tryied to run:
>
> $ make headers_check
>
> but i can't becouse i was that errors:
>
> CHK i
On April 22, 2009 05:23:26 pm Trent Shea wrote:
> Along with the api headers there are "..install.cmd" and ".install" files
> being copied to the built system.
These files get created from scripts/Makefile.headersinst and appear to be log
files.
--
http://linuxfromsc
Hi,
Along with the api headers there are "..install.cmd" and ".install" files
being copied to the built system. They are also present in an ubuntu system,
but they just look like cruft. These files appeared some time after 2.6.24.
Is there a chance that the cp command
;>> Interesting. I've become busy again and haven't had a chance to test the
>>> 2.6.27 headers yet. You must be doing the crazy thing and test-building
>>> from
>>> RH6.2 like I do :-) Nice work on the patch. Did you CC the right kernel
>>> people
Jeremy Huntwork wrote these words on 10/26/08 14:46 CST:
> Yeah, understood. I guess I probably sounded defensive. All I meant was
> there was a decision reached about this earlier and to my knowledge none
> of the technical circumstances have changed, so you'll probably want to
> give consider
Randy McMurchy wrote:
> Jeremy Huntwork wrote these words on 10/26/08 14:34 CST:
>
>> Before you go changing anything, see here:
>
> I didn't mean Bruce should actually change anything. My response was
> more on the technical side in that if it *were* changed, the end
> result of someone followin
Jeremy Huntwork wrote these words on 10/26/08 14:34 CST:
> Before you go changing anything, see here:
I didn't mean Bruce should actually change anything. My response was
more on the technical side in that if it *were* changed, the end
result of someone following the book would be identical to wh
d actually change it to go straight to
>> /usr/include as there should be no files in there at the time
>> of the headers install.
>
> Before you go changing anything, see here:
>
> http://wiki.linuxfromscratch.org/lfs/changeset/8215
>
> and
>
> http://www.linuxfro
lude as there should be no files in there at the time
> of the headers install.
Before you go changing anything, see here:
http://wiki.linuxfromscratch.org/lfs/changeset/8215
and
http://www.linuxfromscratch.org/pipermail/lfs-dev/2007-July/059566.html
--
JH
--
http://linuxfromscratch.org/ma
Bruce Dubbs wrote these words on 10/26/08 14:28 CST:
> OK. I'll add a sentence to explain that.
Would you go ahead and assign yourself ticket #2167 as well?
( http://wiki.linuxfromscratch.org/lfs/ticket/2167 )
--
Randy
rmlinux: [bogomips 3992.15] [GNU ld version 2.17] [gcc (GCC) 4.1.2]
[GNU C
d a sentence to explain that.
> In Chapter 6 we could actually change it to go straight to
> /usr/include as there should be no files in there at the time
> of the headers install.
OK.
Thanks.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
nd was answered)
Anyway, it's because the headers_install process first completely
removes everything in the target directory which would wipe out
the stuff that is in there in Chapter 5.
In Chapter 6 we could actually change it to go straight to
/usr/include as there should be no files in the
Why do we do:
make INSTALL_HDR_PATH=dest headers_install
cp -rv dest/include/* /usr/include
instead of:
make INSTALL_HDR_PATH=/usr/include headers_install
???
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the abo
or
example, before I hit this issue with the kernel's headers scripts,
there's no technical reason why perl 5.6.0 needed to be the minimum
version). But I understand why it's desirable from an editor's
standpoint to set your host pre reqs high.
--
JH
--
http://linuxfromscr
Jeremy Huntwork wrote:
> There is a problem, however. The script uses open() but with 3 arguments
> instead of 2. From what I've found so far, this change in syntax was
> introduced in perl-5.8.0, so the installation of Linux Headers fails if
> the host's version o
Jeremy Huntwork wrote:
> Jeremy Huntwork wrote:
>> There is a problem, however. The script uses open() but with 3
>> arguments instead of 2. From what I've found so far, this change in
>> syntax was introduced in perl-5.8.0, so the installation of Linux
>> Header
Jeremy Huntwork wrote:
> There is a problem, however. The script uses open() but with 3 arguments
> instead of 2. From what I've found so far, this change in syntax was
> introduced in perl-5.8.0, so the installation of Linux Headers fails if
> the host's version o
what I've found so far, this change in syntax was
introduced in perl-5.8.0, so the installation of Linux Headers fails if
the host's version of perl is < 5.8.0. I'm investigating possibilities,
such as modifying the script to use two parameters, but at least for
now, adding
On Sat, Oct 11, 2008 at 02:16:18PM -0500, Randy McMurchy wrote:
> Reece Dunn wrote:
>
> > I asked this question on 21/11/2007 ("Linux Headers question"
> > [http://linuxfromscratch.org/pipermail/lfs-dev/2007-November/060618.html]),
> > which likely resulted in t
Reece Dunn wrote:
> I asked this question on 21/11/2007 ("Linux Headers question"
> [http://linuxfromscratch.org/pipermail/lfs-dev/2007-November/060618.html]),
> which likely resulted in that ticket item. I got essentially the same
> response from Thomas Trepl and Mark R
2008/10/11 Randy McMurchy <[EMAIL PROTECTED]>:
> Hi all,
>
> There's a minor ticket about explaining what the installation
> commands in the Linux Headers installation do, and it occurred
> to me that is it possible that there's a redundant step?
...
> Now here is
Hi all,
There's a minor ticket about explaining what the installation
commands in the Linux Headers installation do, and it occurred
to me that is it possible that there's a redundant step?
Here's the existing commands (with my comments for the
book inserted as well):
First en
sed -i "s/# include /#/" /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 2.6.25.4,
, I've noted the following commands (they've probably always
> been there, just never bothered to noticed) in the Linux Headers
> installation (both Chapter 5 and 6):
>
> make mrproper
> make headers_check
> make INSTALL_HDR_PATH=dest headers_install
>
> T
Hi all,
First of all, thanks to Dan for the cluebat about how gcc bootstraps
by default now. I didn't know that. Perhaps it could be mentioned.
However, I've noted the following commands (they've probably always
been there, just never bothered to noticed) in the Linux Headers
ins
On 21/11/2007, Thomas Trepl <[EMAIL PROTECTED]> wrote:
> Hi Reece,
>
> On Wednesday 21 November 2007 21:35:48 Reece Dunn wrote:
> > Hi,
> >
> > In the sections on building the Linux headers from the kernel sources,
> > the build instructions are (fo
On Wed, 2007-11-21 at 20:35 +, Reece Dunn wrote:
> Hi,
>
> In the sections on building the Linux headers from the kernel sources,
> the build instructions are (for section 6):
>
> make mrproper
> make headers_check
> make INSTALL_HDR_PATH=dest headers_i
Hi Reece,
On Wednesday 21 November 2007 21:35:48 Reece Dunn wrote:
> Hi,
>
> In the sections on building the Linux headers from the kernel sources,
> the build instructions are (for section 6):
>
> make mrproper
> make headers_check
> make INSTALL_HDR_P
Hi,
In the sections on building the Linux headers from the kernel sources,
the build instructions are (for section 6):
make mrproper
make headers_check
make INSTALL_HDR_PATH=dest headers_install
cp -rv dest/include/* /usr/include
What is the rationale behind the last two lines
Matthew Burgess wrote:
> On Tue, 24 Jul 2007 20:50:58 +0600, "Alexander E. Patrakov" <[EMAIL
> PROTECTED]> wrote:
>
>
>> the following failure appears during iptables-1.3.7 compilation against
>> linux-2.6.22.1 headers (spotted during a full rebuild of
On Tue, 24 Jul 2007 20:50:58 +0600, "Alexander E. Patrakov" <[EMAIL PROTECTED]>
wrote:
> the following failure appears during iptables-1.3.7 compilation against
> linux-2.6.22.1 headers (spotted during a full rebuild of the LiveCD):
Any chance you could give iptables-1.3
Hello,
the following failure appears during iptables-1.3.7 compilation against
linux-2.6.22.1 headers (spotted during a full rebuild of the LiveCD):
make[2]: Entering directory `/lfs-livecd/packages/iptables/iptables-1.3.7'
make PREFIX=/usr LIBDIR=/lib BINDIR=/bin MANDIR=/usr/shar
- Original Message -
From: "Dan Nicholson" <[EMAIL PROTECTED]>
To: "LFS Developers Mailinglist"
Sent: Saturday, July 14, 2007 5:38 PM
Subject: Re: Safer linux-headers install
> So, I thought about this a little and decided to just use the hammer
> appro
;s definitely simpler.
So, I thought about this a little and decided to just use the hammer
approach of INSTALL_HDR_PATH=dest, cp dest/include/* /usr/include. I
don't feel real comfortable depending on variables internal to their
headers script. We can change this if the consensus changes, but for
now I
> - Original Message -
> From: "Dan Nicholson" <[EMAIL PROTECTED]>
> To: "LFS Developers Mailinglist"
> Sent: Wednesday, July 11, 2007 3:16 PM
> Subject: Re: Safer linux-headers install
>
>
>> Unless it's going to be accept
- Original Message -
From: "Dan Nicholson" <[EMAIL PROTECTED]>
To: "LFS Developers Mailinglist"
Sent: Wednesday, July 11, 2007 3:16 PM
Subject: Re: Safer linux-headers install
> Unless it's going to be accepted upstream, then I'm not really
&g
- Original Message -
From: "Dan Nicholson" <[EMAIL PROTECTED]>
To: "LFS Developers Mailinglist"
Sent: Wednesday, July 11, 2007 4:02 PM
Subject: Re: Safer linux-headers install
> On 7/11/07, Luca2 <[EMAIL PROTECTED]> wrote:
>>
>> I didn
header tree in ./usr/include by headers_check
and just cp that. Then it's the same number of commands.
make mrproper
make headers_check
cp -rv usr/include/* /usr/include
> Anyway, seeming to remember, there are some kernel headers installed
> (using "make headers_install") w
- Original Message -
From: "Dan Nicholson" <[EMAIL PROTECTED]>
To: "LFS Developers Mailinglist"
Sent: Wednesday, July 11, 2007 3:16 PM
Subject: Re: Safer linux-headers install
> On 7/11/07, Luca2 <[EMAIL PROTECTED]> wrote:
>>
>> Same iss
On 7/11/07, Greg Schafer <[EMAIL PROTECTED]> wrote:
> Dan Nicholson wrote:
>
> > When you run `make headers_install' from the kernel, it will remove all
> > headers not from the kernel list in INSTALL_HDR_PATH. This bites people
> > who try to reinstall them,
On 7/11/07, Luca2 <[EMAIL PROTECTED]> wrote:
>
> Same issue could be solved with a little patch removing or commenting
> out the line in question as I've been already using for some months.
>
> There's ony an additional "issue": it's an extra patch and this depends
> on authors' feelings towards pa
t could be solved the same way with a little "instructions set" before
the "make headers_install", as I've been using to include some extra
headers not sanitizied nor installed by default.
Luca
- Original Message -
From: "Greg Schafer" <[EMAIL PROTEC
Dan Nicholson wrote:
> When you run `make headers_install' from the kernel, it will remove all
> headers not from the kernel list in INSTALL_HDR_PATH. This bites people
> who try to reinstall them,
> I think we should just use a temporary path and cp it to /usr/include
> sin
When you run `make headers_install' from the kernel, it will remove all
headers not from the kernel list in INSTALL_HDR_PATH. This bites people
who try to reinstall them, usually because they want to go back in Ch.
6. Another person got bit by this the other day:
http://linuxfromscratc
On 3/23/07, Randy McMurchy <[EMAIL PROTECTED]> wrote:
> Dan Nicholson wrote these words on 03/23/07 17:03 CST:
>
> > I'm applying this patch now, but I just wanted to touch on the Fedora
> > thing quickly. Their headers are now generated as a separate -headers
> &g
Dan Nicholson wrote these words on 03/23/07 17:03 CST:
> I'm applying this patch now, but I just wanted to touch on the Fedora
> thing quickly. Their headers are now generated as a separate -headers
> package for kernel. This is what it says in the spec file:
Just out of curiosit
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
> >
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.
>
> Patch lo
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.
Patch looks fine to me, feel free to commit it Dan, thanks. Is this worth
reporting upstream (i.
1 - 100 of 431 matches
Mail list logo
