Ignore my former reports - I compiled with 2.0.32 include/linux and include/asm!

Benjamin Redelings I

unread,

Mar 17, 1998, 3:00:00 AM3/17/98

to

The title says it all: I accidentally compiled 2.1.90-pre3 with the
header files
from 2.0.32. When I updated glibc, it automatically ate my for
/usr/include/linux and asm and I didn't realize glibc had been updated
(sigh). Runs MUCH faster now, though!!! ;)

Still, can somebody please introduce some kind of
incompatability for
me so that this kind of thing produces a compile error in the future? I
know I probably should have seen some warnings, but I wasn't looking
closely and the bogus warnings that egcs generates pretty much swamp
everything else.

Except for the my solid lockup, the hybrid kernel wasn't that
bad :)

-BenRI

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.rutgers.edu

Kurt Garloff

unread,

Mar 17, 1998, 3:00:00 AM3/17/98

to

On Mon, Mar 16, 1998 at 11:29:18PM -0800, Benjamin Redelings I wrote:
> The title says it all: I accidentally compiled 2.1.90-pre3 with the
> header files
> from 2.0.32.

I don't believe that!
When you compile your kernel, the Makefiles automatically pass an include
directory to the compiler, e.g. -I/usr/src/Linux-2.1/linux/include, so the
linux and asm includes are taken from the kernel tree your compiling.

There's another issue, though:
When compiling the _libc_ or _glibc_, you should be sure to have the
/usr/include/linux and asm pointing to the correct kernel directories.
The syscalls new to 2.1 or the ones changed from 2.0 might not be used
properly otherwise.
However, this is more a theoretical thing. I'm using a glibc compiled with
2.0.3x and it perfectly works with 2.1.89. Kernel developers have taken care
of compatibility.
Compiling some tools depending strongly on the kernel (because the libc does
not support it), like e.g. net-tools or ibcs2, also requires to have the
correct linux and asm dirs, especially when using libc5. (glibc2 diminishes
the dependency on kernel files.)

> When I updated glibc, it automatically ate my for
> /usr/include/linux and asm and I didn't realize glibc had been updated
> (sigh). Runs MUCH faster now, though!!! ;)

Really?

> Except for the my solid lockup, the hybrid kernel wasn't that
> bad :)

It was no hybrid kernel.

--
Kurt Garloff, Dortmund
<K.Ga...@ping.de>
PGP key on http://student.physik.uni-dortmund.de/homepages/garloff

Matthias Urlichs

unread,

May 1, 1998, 3:00:00 AM5/1/98

to

Kurt Garloff <gar...@kg1.ping.de> writes:
>
> There's another issue, though:
> When compiling the _libc_ or _glibc_, you should be sure to have the
> /usr/include/linux and asm pointing to the correct kernel directories.
> The syscalls new to 2.1 or the ones changed from 2.0 might not be used
> properly otherwise.

For glibc 2.0.9x.current (i.e., the development release), you definitely
should use the 2.1.xx kernel headers. It'll work perfectly with 2.0 kernels.
The other way round, your glibc will not be able to take advantage of 2.1
features (like RT signals, important for pthreads) if you then boot a 2.1
kernel.

--
Matthias Urlichs
noris network GmbH