glibc issues with --enable-kernel=2.6.22.5

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


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


> Here are more specific, but a little clearer seds:
>
> sed -i '213 s/PRIVATE_FUTEX/FUTEX_CLOCK_REALTIME/' \
>    nptl/sysdeps/unix/sysv/linux/x86_64/pthread_rwlock_timedrdlock.S
>
> sed -i '195,210 s/PRIVATE_FUTEX/FUTEX_CLOCK_REALTIME/'
>    nptl/sysdeps/unix/sysv/linux/x86_64/pthread_rwlock_timedwrlock.S
>
> or
>
> sed -i '195,213 s/PRIVATE_FUTEX/FUTEX_CLOCK_REALTIME/' \
>    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
easier.
>
>    -- 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
change.

Gilles




More information about the lfs-dev mailing list