On 7/9/07, Dejan Čabrilo <[EMAIL PROTECTED]> wrote: > > If I try to do: > > make mrproper > make headers_check > make INSTALL_HDR_PATH=/usr headers_install > > the system goes to hell, glibc becomes unusable, compilers fail sanity > checks, etc, and I can't compile anything (thanks god for jhalfs).
We should probably fix this some better way. make headers_install does a "nice" thing before installing the headers. It essentially does `rm -f $(INSTALL_HDR_PATH)/include/*.h'. So, if you run it twice using the commands in the book, you will wipe out /usr/include. The book cheats by assuming your going to do linux-headers, then glibc, then neither again. Try replacing the headers_install command with these two: make INSTALL_HDR_PATH=dest headers_install cp -rv dest/include/* /usr/include > So, my questions are: > > 1a) What does the warning in the SVN book mean by "the ones against > which Glibc was compiled ... the sanitized headers from this Linux > kernel tarball"? Your C libraries need to know some system specifics to get the interfaces to the kernel correct. If you later change the kernel headers in /usr/include, you may be advertising interfaces that your C libraries don't know about or thinks are different. This could cause problems. > 1b) Why can't I reuse what is installed by make headers_install target? > I.e. why did "make headers_install" work in chapter 6, and it doesn't > work after everything was installed (I can't compile anything anymore)? Bad packaging in the kernel. > 2) Do those headers have to match the version of the kernel in use? What > happens if they don't? I suppose I would have to rebuild glibc, but > would other software be affected by headers change if glibc remained the > same? The running kernel doesn't have to match. The version should be greater than or equal to those of the headers. This assumes that the kernel API is stable moving forward, so that running 2.6.21 works even if you have older kernel headers in /usr/include. The opposite is not necessarily true. If you used 2.6.21 headers and then tried to run a 2.6.16 kernel, you could have an application trying to use syscalls that didn't exist back then, for instance. > Whoever got this far gets a beer next time they are in Belgrade :) I > hope this all makes some sense... I hope that helps. Send that beer to Seattle, my trips through Belgrade are scarce. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
