glibc issues with --enable-kernel=

Gilles Espinasse g.esp at
Tue Jan 25 23:42:35 PST 2011

----- Original Message ----- 
From: "Bruce Dubbs" <bruce.dubbs at>
To: "LFS Developers Mailinglist" <lfs-dev at>
Sent: Tuesday, January 25, 2011 7:18 PM
Subject: Re: glibc issues with --enable-kernel=

> Here are more specific, but a little clearer seds:
>    nptl/sysdeps/unix/sysv/linux/x86_64/pthread_rwlock_timedrdlock.S
>    nptl/sysdeps/unix/sysv/linux/x86_64/pthread_rwlock_timedwrlock.S
> or
>    nptl/sysdeps/unix/sysv/linux/x86_64/pthread_rwlock_timed{rd,wr}lock.S
> Actually, using one of these provides an educational example of how to
> specify an address range for a sed.
> The above would need to be checked for any new release, but we need to
> do that anyway for a patch and checking/changing these seds would be
>    -- Bruce

I agree that sed could be a gain for simple change that are unlikely to
break. But breaking for a patch is a feature when code change that could be
controlled by diff context size and patch --fuzz

What is the gain of a sed expression that need to be checked on upgrade when
a diff could be made with a larger context and by safer?
Something like a diff --unified=6 would have more luck to break if code


More information about the lfs-dev mailing list