Re: [glibc/f21] Resolves: #1146967.
by Siddhesh Poyarekar
On Fri, Sep 26, 2014 at 03:34:22PM +0000, Carlos O'Donell wrote:
> commit f4db47775a019670fb3fcfa7b949d4ea190dacca
> Author: Carlos O'Donell <carlos(a)redhat.com>
> Date: Fri Sep 26 11:33:51 2014 -0400
>
> Resolves: #1146967.
>
> - Disable lock elision support for Intel hardware until microcode
> updates can be done in early bootup (#1146967).
>
> glibc.spec | 12 ++++++++++--
> 1 files changed, 10 insertions(+), 2 deletions(-)
> ---
> diff --git a/glibc.spec b/glibc.spec
> index 0d02975..525fe13 100644
> --- a/glibc.spec
> +++ b/glibc.spec
> @@ -1,6 +1,6 @@
> %define glibcsrcdir glibc-2.20
> %define glibcversion 2.20
> -%define glibcrelease 3%{?dist}
> +%define glibcrelease 4%{?dist}
> # Pre-release tarballs are pulled in from git using a command that is
> # effectively:
> #
> @@ -691,6 +691,11 @@ build()
> build_CFLAGS="$BuildFlags -g -O3 $*"
> # Some configure checks can spuriously fail for some architectures if
> # unwind info is present
> + #
> + # At the moment lock elision is temporarily disabled until we work
> + # out how to update the microcode in early boot to prevent the cpuid
> + # results from becoming stale. Once this is fixed add back:
> + # --enable-lock-elision \
> configure_CFLAGS="$build_CFLAGS -fno-asynchronous-unwind-tables"
> ../configure CC="$GCC" CXX="$GXX" CFLAGS="$configure_CFLAGS" \
> --prefix=%{_prefix} \
> @@ -707,7 +712,6 @@ build()
> %ifarch ppc64p7
> --with-cpu=power7 \
> %endif
> - --enable-lock-elision \
This should be done conditionally, i.e. disable for x86_64, but keep
enabled for s390x. That's probably not necessary for f20 since x86_64
is the only arch that has elision support there.
In fact, I'd go for something like:
%define elision_arches s390 s390x
...
%ifarch %{elision_arches}
--enable-lock-elision
%endif
Siddhesh
9 years, 8 months
Trim ChangeLogs?
by Carlos O'Donell
Siddhesh,
Would you be opposed to moving all ChaneLogs from
2013 and earlier into a ChangeLog.old file, thus pruning
the %changelog section in the glibc.spec file?
I can't see anyone using this actively in the rpm,
but leaving it in a checked in file e.g. ChangeLog
means we can look at it later. It solves the onerous
problem that no matter what you search for in the file
you're bound to find that word or text in the ChangeLog
and that's getting annoying and old.
If nobody objects I'll prune the glibc.spec file and
move the old data into a ChangeLog.old file.
Cheers,
Carlos.
9 years, 9 months