Who understands this code?

Greg Schafer gschafer at zip.com.au
Fri Mar 14 03:04:40 PST 2003

On Fri, Mar 14, 2003 at 11:29:50AM +0100, Matthias Benkmann wrote:
> Strange. I can't reproduce this even with a system more recent than that:


> And, I don't want to start a new flamewar,

Thanks, I appreciate that :-)

> but have you built the system
> without ANY kind of optimizations (setting the default architecture GCC
> compiles for and other stuff that's "not supposed to make a difference"
> counts as optimization) and tweaks?

No, of course not :-) I live in tweak city, remember? The only 2 tweaks I
can think of that could possibly be pertinent here are 1) the whole shebang
was compiled with -march=i686 and 2) glibc was configured with
--enable-kernel=current (i.e. 2.4.20)

That is why I asked other people to check their logs so I can ascertain
whether this is a generic problem or just mine only. I know it was only a
few hours ago but so far only Ronald has responded and I'm quite saddened
that many folk seem not to keep build logs :-(

> I've attached my ct-mmap to this message. Does it fail in your chroot?


> If
> it does I think we can eliminate GCC/binutils as a cause for the problem.
> In that case I could mail you my glibc to see if replacing that will make
> a difference.
> If the problem still persists this only leaves the kernel I think.

But what about the ld.so.cache weirdness? That seems to make a difference
here. Early in the chroot build, the cache is small and I see the problem.
But later when it gets bigger, no problem. 

Feel free to mail your glibc but I'm not sure it will help but worth a shot
I s'pose. Just make sure you bzip it :-) Thanks.

Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message

More information about the lfs-dev mailing list