Jeremy Huntwork wrote:
Alright, I can see where you're coming from. So ideally, to make use of
the 'headers_check' target, you would run something like:
make mrproper
make headers_install
make headers_check
cp -av usr/include/* /tools/include
This would be my preferred set of instructions.
Jeremy Huntwork wrote:
> But if that's the case, headers_check re-runs everything you
> just did in 'headers_install', which makes the 'headers_install' kind of
> pointless. To me, it seems more like 'headers_check' is an extension of
> 'headers_install', adding an extra step of verification.
Greg Schafer wrote:
FFS, this whole new way of obtaining sanitized headers has become known as
the "make headers_install" method and you've gone and removed that very
command! Not very educational IMHO. Hope it's clearer now.
Alright, I can see where you're coming from. So ideally, to make use
Jeremy Huntwork wrote:
> Have you actually studied the Makefile contents? The results of the
> current commands would be the same as if you ran (which, btw, would also
> avoid the problem with removing /tools/include):
>
> make mrproper
> make headers_check
> make headers_install
> cp -av usr/
Greg Schafer wrote:
Ummm, you completely missed the point. The /tmp removal stuff is fine. The
removal of `make headers_install' is what's questionable.
Have you actually studied the Makefile contents? The results of the
current commands would be the same as if you ran (which, btw, would also
Jeremy Huntwork wrote:
> This has nothing to do with the way other packages work. This is *only*
> applicable with this particular package and its Makefile. Why make a
> temporary directory outside the build tree, install it there first, and
> then manually move it to its final location when it
Greg Schafer wrote:
Jeremy Huntwork wrote:
This is because the target 'headers_check' includes 'headers_install' as
a dependency, and therefore runs that first:
You're obfuscating here for no good reason. In fact, your logic is flawed.
Taking your view to extremes, why even specify "make" when
Jeremy Huntwork wrote:
> Actually, after looking through the Linux Makefile a bit, I think our
> commands for chapter 5 linux-headers can be simplified to the following:
>
> patch -Np1 -i ../linux-2.6.18.1-unifdef-1.patch
> make mrproper
> make headers_check
> cp -Rv usr/include/* /tools/include
Jeremy Huntwork wrote:
Dan Nicholson wrote:
I like this better. Cleaner, shorter, and it uses the defaults from
the package. And doing the check doesn't hurt ever. Jeremy, what tools
are needed in the check? I just don't want to add to the host system
requirements for the Ch. 5 headers.
Not su
Dan Nicholson wrote:
I like this better. Cleaner, shorter, and it uses the defaults from
the package. And doing the check doesn't hurt ever. Jeremy, what tools
are needed in the check? I just don't want to add to the host system
requirements for the Ch. 5 headers.
Not sure what it uses when che
On 11/11/06, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
Jeremy Huntwork wrote:
> If you don't like the above approach, then I suggest we put in an explanation
as
> to why we install to a temporary directory first and add the '-v' flag to the
cp
> command.
Actually, after looking through the Li
Jeremy Huntwork wrote:
If you don't like the above approach, then I suggest we put in an explanation as
to why we install to a temporary directory first and add the '-v' flag to the cp
command.
Actually, after looking through the Linux Makefile a bit, I think our
commands for chapter 5 linux-h
Dan Nicholson gmail.com> writes:
> On 9/25/06, Matthew Burgess linuxfromscratch.org> wrote:
> >
> > What about something like:
> >
> > tar -xf linux-2.6.18.x.tar.bz2
> > cd linux-2.6.18.x
> > mkdir /tools/tmp
> > make mrproper
> > make headers_check # For testing
> > make INSTALL_HDR_PATH=/tools/
On 10/19/06, Dan Nicholson <[EMAIL PROTECTED]> wrote:
Testing out my minimal C skills, I came up with the attached patch. It
built for me, but I don't have a system with the new headers to test
against. YMMV.
That patch was bad. capset needs to be defined so that the libcap
implementation can
On 10/19/06, Dan Nicholson <[EMAIL PROTECTED]> wrote:
On 9/28/06, Jim Gifford <[EMAIL PROTECTED]> wrote:
> Found the second on besides Dan's util-linux one. Vsftpd, caused by the
> syscalls being removed from unistd.h, anyone got any ideas.
> gcc -m64 -c sysdeputil.c -O2 -Wall -W -Wshadow -idir
On 10/19/06, Jim Gifford <[EMAIL PROTECTED]> wrote:
I actually talked with the Linux MIPS guys and they gave me some ideas,
I came up with this patch and so far it seems to do the job.
http://svn.cross-lfs.org/svn/repos/patches/vsftpd/vsftpd-2.0.5-syscall-1.patch
Interesting. I did a bit of go
I actually talked with the Linux MIPS guys and they gave me some ideas,
I came up with this patch and so far it seems to do the job.
http://svn.cross-lfs.org/svn/repos/patches/vsftpd/vsftpd-2.0.5-syscall-1.patch
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfroms
On 9/28/06, Jim Gifford <[EMAIL PROTECTED]> wrote:
Found the second on besides Dan's util-linux one. Vsftpd, caused by the
syscalls being removed from unistd.h, anyone got any ideas.
gcc -m64 -c sysdeputil.c -O2 -Wall -W -Wshadow -idirafter dummyinc
sysdeputil.c:162: error: expected declaration
Found the second on besides Dan's util-linux one. Vsftpd, caused by the
syscalls being removed from unistd.h, anyone got any ideas.
gcc -m64 -c sysdeputil.c -O2 -Wall -W -Wshadow -idirafter dummyinc
sysdeputil.c:162: error: expected declaration specifiers or '...' before
'capset'
sysdeputil.c:
Greg Schafer wrote:
> unifdef will be included in the kernel tree for 2.6.19. It's already
> committed in Linus's tree post 2.6.18.
Oh. Well, that's better once we get 2.6.19, then...
> It seems silly adding a crufty pkg to LFS that'll soon be ripped out.
Yeah, I'd agree with that. Especially
Bryan Kadzban wrote:
> Hmm; it looks like unifdef is not included in the kernel tree. We're
> going to have to add this to chapter 5. (Actually we'll have to build
> it just before the kernel headers install in chapter 5; then we might as
> well just use the version from /tools in chapter 6 also
On Monday 25 September 2006 19:24, Matthew Burgess wrote:
> Just wondering what the preferred approach would be for upgrading Linux
> to the latest version (2.6.18 at the time of writing)? Previously,
> we've just upgraded the kernel regardless of the headers it wants
> installed because of having
On Monday 25 September 2006 23:20, M.Canales.es wrote:
> ...
> > The only gotcha is in the last step because headers_install does `rm
> > -rf $INSTALL_HDR_PATH/include'. So, maybe we'd want to let it install
> > in the kernel tree and copy it ourselves. But, that's basically what
> > you'll be up a
On 9/25/06, Bryan Kadzban <[EMAIL PROTECTED]> wrote:
Dan Nicholson wrote:
> Here are the relevant make bits:
>
> $(Q)unifdef -Ux /dev/null
Hmm; it looks like unifdef is not included in the kernel tree. We're
going to have to add this to chapter 5. (Actually we'll have to build
it just be
Dan Nicholson wrote:
> Here are the relevant make bits:
>
> $(Q)unifdef -Ux /dev/null
Hmm; it looks like unifdef is not included in the kernel tree. We're
going to have to add this to chapter 5. (Actually we'll have to build
it just before the kernel headers install in chapter 5; then we
Dan Nicholson wrote:
On 9/25/06, Matthew Burgess <[EMAIL PROTECTED]> wrote:
What about something like:
tar -xf linux-2.6.18.x.tar.bz2
cd linux-2.6.18.x
mkdir /tools/tmp
make mrproper
make headers_check # For testing
make INSTALL_HDR_PATH=/tools/tmp headers_install
cp -R /tools/tmp/include/* /t
On 9/25/06, Matthew Burgess <[EMAIL PROTECTED]> wrote:
Personally, I think this should be tackled in a 2-step approach. 1)
Simple version bump to 2.6.18. 2) Drop linux-libc-headers installation,
replacing it with 'make headers_install' from the kernel tarball.
Oh, yeah. I got sidetracked read
On 9/25/06, Matthew Burgess <[EMAIL PROTECTED]> wrote:
What about something like:
tar -xf linux-2.6.18.x.tar.bz2
cd linux-2.6.18.x
mkdir /tools/tmp
make mrproper
make headers_check # For testing
make INSTALL_HDR_PATH=/tools/tmp headers_install
cp -R /tools/tmp/include/* /tools/include
rm -r /to
El Lunes, 25 de Septiembre de 2006 23:12, Dan Nicholson escribió:
> > linux-headers) echo $(grep "^linux-headers.*.bz2"
> > $JHALFSDIR/pkg_tarball_list | head -n1 ) ;;
>
> But the tarball name will probably not be linux-headers-*.bz2. It will
> probably be linux-2.6.18.x since you do the installat
Dan Nicholson wrote:
On 9/25/06, M.Canales.es <[EMAIL PROTECTED]> wrote:
El Lunes, 25 de Septiembre de 2006 22:45, Matthew Burgess escribió:
> I was going to simply call it "Linux Headers" and have it being written
> out to "linux_headers.html". Does that help you at all?
Yes. With that we ca
On 9/25/06, M.Canales.es <[EMAIL PROTECTED]> wrote:
El Lunes, 25 de Septiembre de 2006 22:45, Matthew Burgess escribió:
> I was going to simply call it "Linux Headers" and have it being written
> out to "linux_headers.html". Does that help you at all?
Yes. With that we can know that the needed
El Lunes, 25 de Septiembre de 2006 22:45, Matthew Burgess escribió:
> I was going to simply call it "Linux Headers" and have it being written
> out to "linux_headers.html". Does that help you at all?
Yes. With that we can know that the needed change is to replace in
get_package_tarball_name() f
On Mon, 2006-09-25 at 21:35 +0100, Matthew Burgess wrote:
> Jim Gifford wrote:
>
> > the bottom line is that there will be some major breakages from the
> > headers_install, are you ready to tackle those?
>
> As Dan and I (at least) have previously stated, yes, we're prepared to
> tackle any BL
M.Canales.es wrote:
In this case (headers installed from the kernel sources) the issue is about
html_page_name-->build_script_name-->package_name mapping, and that can't be
done until know how that new "Headers Installation" page will be called.
I was going to simply call it "Linux Headers" a
El Lunes, 25 de Septiembre de 2006 21:39, Dan Nicholson escribió:
> I've been thinking about this for a while. Is there any reason why
> jhalfs doesn't use the $package-url entity to find out the tarball
> instead of assuming that there is a 1:1 mapping between package and
> tarball?
> With a sma
Jim Gifford wrote:
the bottom line is that there will be some major breakages from the
headers_install, are you ready to tackle those?
As Dan and I (at least) have previously stated, yes, we're prepared to
tackle any BLFS breakage (others are welcome to help out too).
Regards,
Matt.
--
ht
Jim Gifford wrote:
Guys,
Using make headers_install will work for x86 and x86_64, but there
are a lot of issues and going to be a lot of breakage with BLFS. So I
hate to say this, but CLFS will be remaining with our linux-headers
package. Just as an FYI, Slackware, Slamd64, and others have
Guys,
Using make headers_install will work for x86 and x86_64, but there
are a lot of issues and going to be a lot of breakage with BLFS. So I
hate to say this, but CLFS will be remaining with our linux-headers
package. Just as an FYI, Slackware, Slamd64, and others have adopted the
CLFS pa
On 9/25/06, M.Canales.es <[EMAIL PROTECTED]> wrote:
For jhalfs, first we must to make mandatory the linux kernel package download
(at this moment the kernel download/build is optional to allow folks to
upgrade their kernel sources using patches). Then we will need to map the new
headers page sc
Matthew Burgess wrote:
Hi folks,
Incidentally, has anyone done any work on getting the headers_install
approach integrated with jhalfs. Is any specific support required, or
does it just require the "linux-libc-headers" page being replaced with a
"linux headers" page?
yes.. changing the
> Personally, I think this should be tackled in a 2-step approach. 1)
> Simple version bump to 2.6.18. 2) Drop linux-libc-headers installation,
> replacing it with 'make headers_install' from the kernel tarball. That
> way, if the headers_install thing is not feasible for the time being, we
> do
41 matches
Mail list logo
