> My scripts have used the kernel's own headers for some months > without problems on x86* and ppc, but I'm using the old > INSTALL_HDR_PATH=/usr which is known to overwrite userspace headers > on a rebuild. I don't know if the i386 headers are needed or not.
Fact is the system 'apparently' built with no noticeable errors or suspicious messages, so I think it was fine, but I would like to refine the header installation method, as I'm sure there's a far better way to do it (or at least that's what I think at the moment :P) > The only problem with doing the simpler cp -av dest/include/* > /usr/include is that it will overwrite the glibc headers (might be > fixed for 2.6.23, or else for 2.6.24, depending on what path the > patch takes to get to linus). Hmm... if I create a script or better said, a set of scripts that 'in a certain way' act like a database manager like doing something like SELECT DISTINCT, I mean... I only copy the headers from the kernel tarball that aren't actually present in the include directory... would that guarantee a cleaner build? what's the exact method followed by distro builders in the 'kingdoms' of Fedora, Ubuntu and similar? > I've heard that other architectures have issues with the kernel's > own headers. Without the hardware, I can't comment. I didn't know > that 2.6.21.3 was in the ftp directory, the book is still at > 2.6.20.1. AFAIK I don't have the ability to upload a new headers > tarball, and anyway the kernel's own headers work fine for me - > the one thing you didn't mention is that sysvinit needs a different > patch when used with the kernel's own headers (same patch as in > LFS). Hmm... could you tell me what exact patch is it? never heard of it, at least not AFAIK :S > Of course, 2.6.22.2 should be out in the next couple of days > (deadline for comments was 19:00 UTC tonight, if I remember > correctly). Correct, it's already released, and as it contains some code for the i386 architecture from the Changelog, maybe it's a good reason for me for a complete rebuild. > Those messages from Mesa are normal. I'm still hoping that by > xorg-7.3 it will use a more normal configure system. That's the kind of behaviour that actually _bug_ me, so to remedy the situation, basically I symlinked the first 3 includes from the /usr/lib/<path to gcc> hierarchy to the /usr/include and for the limits.h I couldn't do anything as the file calls itself with a macro, given the internal explanation that can be done in the case the kernel limits are not good enough to use to be able to use the gcc limits for a given compilation (at least that's what I recall from reading the file), but... is this a fine solution or is it more like a 'patch' for the problem? Julio _______________________________________________ Clfs-support mailing list [email protected] http://lists.cross-lfs.org/cgi-bin/mailman/listinfo/clfs-support
