Hi, On Mon, 8 Oct 2007 00:44:21 +0200 Volker Armin Hemmann <[EMAIL PROTECTED]> wrote:
> ok, example. I might be totally wrong, so don't believe me: > The splice system call was added with 2.6.17 and corresponding headers. If > you build an application that has optinal (on compile time) support for this, > but downgrade the headers after that to say... 2.6.10 you might see funny > stuff happening. Nah, you won't. Nothing depends on the headers on runtime, they just matter on compile time. After downgrading, when you compile new stuff, it will use the now older headers, i.e. it will probably rely on older feature sets. Whether the software compiled against newer headers will still work depends solely on the kernel. In your example, when you also decide to run a 2.6.10 kernel, then the software relying on newer features (due to the newer headers on compile time) will have problems. > Headers are backward compatible, not forward compatible. That's not true how you have put it. But it is a misleading thing, all this. The _kernel_ has a backward compatible interface to userland (most of the time, and almost definitely regarding the syscalls). That's why you can still run that old statically compiled binary from 19-you-know-what. The _headers_ on the opposite belong more to the userland software camp. They are what userland knows about the kernel at compile time. So _if_ the kernel keeps backward compatibility, the _headers_ are forward compatible. (The underscoring is meant as emphasis, but not to be harsh) > glibc is similar - just try to downgrade glibc. You can't, portage won't > allow > it. That's the same for downgrading the kernel and it works the same: Userland is compiled against newer glibc headers. -hwh (It's all somewhat complicated, that's why I thought the short one-liner wasn't a definite answer...) -- [EMAIL PROTECTED] mailing list
