glibc issues with --enable-kernel=

Bruce Dubbs bruce.dubbs at
Wed Jan 26 10:36:25 PST 2011

Gilles Espinasse wrote:

> From: "Bruce Dubbs" <bruce.dubbs at>

>>    nptl/sysdeps/unix/sysv/linux/x86_64/pthread_rwlock_timed{rd,wr}lock.S

> 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
> change.

The gain is that someone can see at a glance what the changes are. 
There is no extra file download.  The sed above is really simple because 
there are no wildcards or escaped characters.  Adding the numerical 
addresses also has an educational aspect, which is one of the goals of 
the book.

If a user applies a sed like this to a version of the package not in the 
book, then it could silently break.  Whose responsibility is that?

Hopefully the next version of glibc will have the fix and the sed will 
not be required.

   -- Bruce

More information about the lfs-dev mailing list