----- Original Message -----
From: "Bruce Dubbs" <[email protected]>
To: "LFS Developers Mailinglist" <[email protected]>
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
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
