Hi, I'm back from FOSDEM and the updated slides of our Owl presentation as used at FOSDEM are now online: http://www.openwall.com/presentations/ On Thu, Feb 20, 2003 at 02:26:13AM +0100, Maciek Pasternacki wrote: > Jarno Huuskonen <Jarno.Huuskonen@private> writes: > > > On Sat, Feb 15, Maciek Pasternacki wrote: > >> Why /usr/include/linux and /usr/include/asm in Owl are symlinks and > >> not copies of headers against which glibc was built? Shouldn't these > >> be part of glibc package, or at least be independent from whatever > >> goes into /usr/src/linux? > > > > I think RedHat 6.2 uses those same symlinks (and if you're going to > > install 2.4.x kernel, then 2.4.x include files get used). Jarno is correct about the 6.2, but they (Red Hat) have changed it since then. Note that I am saying "changed" rather than "corrected" because this is a non-obvious choice to me. > Yes, this is the problem. The includes in /usr/include/linux and > /usr/include/asm should not match currently running kernel, s/should not/don't have to/ > but should be the ones against which glibc was compiled. For guaranteed-correct builds of purely-userspace applications, without letting them use some functionality introduced with newer kernels, yes. However, there're also valid reasons to want to build applications or especially kernel modules with newer kernel headers. > If some struct > definition changes under the feet, keeping binary compatibility but > e.g. changing size, then it may break som glibc's routines which use > the old size or some arcane cpp macros in glibc's headers. I think Linus used a better example in the linux-kernel discussion you've previously referred to (thanks!) I personally prefer manual control over which kernel headers I use and which kernel I run. Yes, we currently have these symlinks, but /usr/src/linux doesn't have to match the running kernel (although that is often convenient). It's only /boot/System.map (or one of its alternate pathnames) and modules which should match the running kernel. In practice, it is usually safe to build applications against newer Linux 2.2.x kernel headers than those glibc was built with. It should be the same for different 2.4.x's. Mixing 2.2.x and 2.4.x is not so safe, but even that is sometimes reasonable: currently, our glibc is built against 2.2.x, but if you actually run 2.4.x and want to build iptables, you have to build it against the 2.4.x kernel headers. And it works, despite the version difference with the glibc build. If we were to "hard-package" the kernel headers that glibc was built against, doing such builds would become even more of a hack. But you've brought up a valid problem that I'd like to deal with, -- I am just not sure of how to better approach it such that we both ensure correctness and don't reduce flexibility. -- /sd
This archive was generated by hypermail 2.1.3 : Sun Jan 15 2006 - 13:43:18 PST