H J Lu wrote:
> I look at the glibc code. It uses a constant RLIM_INFINITY for a given
> arch. The user always passes (~0UL) to glibc on x86. glibc will check
> if the kernel supports the new getrlimit at the run time. If it
> doesn't, glibc will adjust the RLIM_INFINITY for setrlimit. I
> don't see
> how glibc 2.2.5 compiled under kernel 2.2 will fail under 2.4 due to
> this unless glibc is misconfigureed or miscompiled.
It's not a question of which kernel glibc is compiled under, it's a question
of which version of the kernel headers (/usr/include/{linux,asm}) glibc is
compiled against.
A glibc, even the newest glibc, *compiled against 2.2 headers* cannot know
about the new getrlimit, so the run-time test cannot be compiled and is not
used. Such a glibc subsequently breaks fsck if run under a 2.4 kernel.
Recompile your glibc against 2.4 headers and you should get a glibc and fsck
that work if run under either a 2.2 or 2.4 kernel.
The necessary kernel patch to fix this mess is in the latest -pre-ac (thanks
Alan).
Peter
On Mon, Mar 25, 2002 at 02:52:24AM -0800, Peter Hartley wrote:
> H J Lu wrote:
> > I look at the glibc code. It uses a constant RLIM_INFINITY for a given
> > arch. The user always passes (~0UL) to glibc on x86. glibc will check
> > if the kernel supports the new getrlimit at the run time. If it
> > doesn't, glibc will adjust the RLIM_INFINITY for setrlimit. I
> > don't see
> > how glibc 2.2.5 compiled under kernel 2.2 will fail under 2.4 due to
> > this unless glibc is misconfigureed or miscompiled.
>
> It's not a question of which kernel glibc is compiled under, it's a question
> of which version of the kernel headers (/usr/include/{linux,asm}) glibc is
> compiled against.
>
What are you talking about? It doesn't matter which kernel header
is used. glibc doesn't even use /usr/include/asm/resource.h nor
should any user space applications.
H.J.