On Sat, Aug 11, 2007 at 12:31:36AM +0200, Julio Meca Hansen wrote: > > 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) > Upstream (both toolchain and kernel) think the 'amd64' way of doing things is silly. Within the kernel, there are non-obvious inclusions between x86_64 and i386, which is one reason why people have proposed merging both into an x86 architecture. I suppose it is possible to find out what these inclusions are, and then look to see if they apply, or not, to the sanitised headers. For me, that isn't a sensible use of my time - I'm not even sure if I would be able to spot the cross-arch inclusions. Copying everything (or everything except scsi) is simple and known to work. > > 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? > For fedora, get the kernel srpm, use rpm2cpio and cpio to extract the contents, then read the *.spec file to see what they do (the same srpm is used to build the kernel and to build the headers).
For ubuntu, the answer _might_ be available if you look at the appropriate *.diff.gz, the problems are that all debian-derived distros use scripts to apply any patches (that is tedious to break down so that you can get the patches) and anyway it isn't always obvious how they configure things - but then, I haven't ever looked at/or header source for ubuntu. > > 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 > Mea culpa - sysklogd, not sysvinit : sysklogd-1.4.1-fixes-2.patch. Without it, failed to compile with an earlier kernel and the kernel's own headers (/me wishes there was a _short_ unambiguous phrase for "the kernel's own sanitised headers"). > > 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. > But, does it affect the sanitised headers ? Changes within the kernel, for an architecture you aren't using, don't seem like a reason to rebuild! To give you a different perspective - I often build new kernels frequently. I've never yet found a reason to upgrade a _system_ for a new kernel. > > 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 > To me, you are trying to fix messages which are ugly, and confusing, but which do not indicate a problem with the system (it builds ok despite the messages). At best, your additional symlinks won't do any harm :-o ĸen -- das eine Mal als Tragödie, das andere Mal als Farce _______________________________________________ Clfs-support mailing list [email protected] http://lists.cross-lfs.org/cgi-bin/mailman/listinfo/clfs-support
