Re: Several glibc problems...
On Wed, 18 Nov 1998 09:46:36 +0100, Christian Meder wrote:
>
>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.
This is a bug, I'll fix it this evening. Do you know if it's a
problem with libc 2.0 as well? Was sig(alt)stack the only problem?
>lsof sources will get really interesting with glibc2.1. The sources are
>already undefining lots of stuff to get along with glibc2.0 ;-)
Hmm, could you be more specific? We'd like to make its job easier if
possible.
>>
>> 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.
kernel-headers provides the headers that go in
/usr/include/{linux,asm} which are not the headers that you
necessarily want to use to compile libc. To make matters more
confusing, libc6 puts headers in /usr/include/{linux,asm} too. Dale
should do this:
- depend on kernel-headers-2.0.x for some safe x to provide
/usr/include/{linux,asm}
- put a PRIVATE copy of the include subdirectory from a recent 2.1
kernel into the libc6 source package, use that to compile libc, then
throw it away.
That gets you libc compiled the way it wants, and keeps the stable
/usr/include/linux stuff that Debian wants.
>> 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 ?
There may well have been, I don't follow kernel development real
closely.
zw
Reply to: