Re: Several glibc problems...
On Tue, Nov 17, 1998 at 11:44:28AM -0500, Zack Weinberg wrote:
>
> Dale Scheetz wrote:
> > 3. kernel headers
> >
> > The sparc ports, along with several other of the ports (maybe all?) are
> > using kernels from the 2.1 development tree. As a result they are also
> > using 2.1 glibc pre-releases. The upstream maintainers of glibc are also
> > mostly working with the 2.1 kernels in their development, so this is a
> > reasonable thing to do. For the intel release, however, we have never used
> > a "development" kernel in a release, so from my position, this transition
> > is ... well, difficult.
>
> The deal is this. If you compile glibc (2.0 or 2.1) against 2.1 kernel
> headers, it is made aware of 2.1 kernel features. Wrappers are generated
> for 2.1-only system calls, some functions attempt to use 2.1 interfaces
> internally. In all cases, the library detects at runtime if a 2.0 kernel is
> in use, and falls back sanely. You might see 'unimplemented syscall' log
> messages on some platforms (Alpha?), but everything continues to work.
Just some experiences:
We use glibc2.1 with 2.1.125 headers on Debian Sparc 2.0.35 (and Powerpc
2.1.125) and it
works pretty well. We had to disable the annoying unimplemented syscall
messages from the sparc kernel because otherwise your console gets flooded ;-)
There was one problem though:
The glibc2.1 with the 2.1.125 headers is aware of the sigaltstack syscall
from Linux 2.1.x. If you compile a program which uses sigaltstack (or
sigstack which calls sigaltstack) it will compile flawlessly but it won't
run on a 2.0.x kernel because sigaltstack has no wrapper.
My solution was to disable the syscalls which weren't wrapped for now.
>
> Once the library is compiled and installed, it doesn't care which kernel
> headers appear in /usr/include/linux and /usr/include/asm. It'd be
> perfectly legitimate to keep those at 2.0.32 and still compile the library
> with 2.1 headers. Programs that reference <linux/foo.h> directly may have
> problems but we've been saying not to do that for ages now.
lsof sources will get really interesting with glibc2.1. The sources are
already undefining lots of stuff to get along with glibc2.0 ;-)
>
> We (upstream) say you should always use 2.1 headers to compile libc 2.0 and
> 2.1 because then you won't have to rebuild libc if you decide to try a 2.1
> kernel. The --with-headers configure switch (only in libc 2.1 I think)
> allows you to do that without changing /usr/include. The source package
> could have a copy of the kernel headers in a private location, refer to them
> during the build, and then throw them away. Just make sure you run 'make
> config' on the kernel tree before copying its headers (otherwise
> linux/version.h doesn't exist), and change the asm->asm-xyz link for the
> architecture in debian/rules before running configure.
It's best on Debian to use a kernel-headers package produced by Manoj's
kernelpackage. It installs in the right place and it is correct.
>
> The precise version of the kernel headers doesn't matter as long as you use
> a sufficiently recent one. I think the last change that mattered was in the
> 2.1.9x series, but I could be wrong.
Wasn't there some correction with O_DIRECTORY from 2.1.126 or something ?
Greetings,
Christian
--
Christian Meder, email: meder@isr.uni-stuttgart.de
What's the railroad to me ?
I never go to see
Where it ends.
It fills a few hollows,
And makes banks for the swallows,
It sets the sand a-blowing,
And the blackberries a-growing.
(Henry David Thoreau)
Reply to: