lkml.org 
[lkml]   [1996]   [Mar]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Horrible things with 1.3.78
Snow Cat writes:
> I think current solution is good for reducing number of bugs in
> kernel+libc. Imagine what would happen if somebody changed a major
> structure, like stat in the kernel but forget to update libc
> include files. Users won't be able to either use old binaries or
> compile new ones and there is also a chance that more subtle
> disperancies could go unnoticed for long time.

Huh?

Unless you changed libc, the old stat would continue to work. If you
upgraded libc's implementation of stat and didn't upgrade the headers,
stat would break.

For the existing headers to break with the existing libc, existing
programs would also break. If there's good reasons for letting the
headers used for user programs drift independent of the compiler
tools, this isn't one of them.

> The real way to help novice users is to put together
> mini-distributions, including kernel, libc and kernel-dependant
> packages like ppp, that have been verified to work together.

If the compiler tools have been verified to work, and the kernel
provides the same interfaces that the tools were designed for, why
introduce an extra step?

Personally, I've long since made /usr/src/linux a soft link. At the
moment, I mangage things by pointing the link at some older headers
when I'm compiling ordinary programs, and at the kernel headers when
I'm compiling kernel-version-specific programs. This only works
because I'm careful to not use gcc for the wrong thing at the wrong
time.

It's particularly amusing in one case (dosemu) where the software
*doesn't* reference /usr/src/linux/include at compile time (it expects
the version specific includes to just be there with #include <>).
Yet, some of it *does* reference /usr/src/linux/ at run-time to find
System.map. [One of these days I might decide I care enough to track
down the bit of code that uses System.map.]

Sure, dosemu is alpha and all that, but the underlying assumptions its
coded against are broken. [And, dosemu isn't the only bit of code
that's kernel-version dependent.]

Anyways, the real problem here is code which needs to get at
kernel-version-specific includes but which doesn't explicitly use any
kernel-version-specific include directives. That, and the linux
README that, as of 1.3.80 says:

- make sure your /usr/include/linux and /usr/include/asm directories
are just symlinks to the kernel sources:

cd /usr/include
rm -rf linux
rm -rf asm
ln -s /usr/src/linux/include/linux linux
ln -s /usr/src/linux/include/asm-i386 asm

--
Raul


\
 
 \ /
  Last update: 2005-03-22 13:36    [from the cache]
©2003-2011 Jasper Spaans