Create a new package glibc-benchtests with the benchmark binaries that
one may download and run to benchmark glibc for their machine. More
importantly, the glibc-bench-compare and bench.mk scripts can run
benchmarks and compare performance of two arbitrary glibc versions as
long as both versions have the glibc-benchtests package.
Usage:
Scenario 1: Compare two build numbers, e.g.:
/usr/libexec/glibc-benchtests/glibc-bench-compare 2.20-1.fc21 2.21.90-11.fc22
If a second build is omitted, comparison is done with the currently
installed glibc.
Scenario 2: Compare two downloaded rpms - only glibc, glibc-benchtests
and glibc-common are needed for both versions. e.g.:
/usr/libexec/glibc-benchtests/glibc-bench-compare -p <dir1> <dir2>
Fix up a Fedora patch to pass the address of the mutex in the mstate
instead of the mstate itself. This fizes the Werror warning seen on
all non-x86 builds.
- Disable lock elision support for Intel hardware until microcode
updates can be done in early bootup (#1146967).
- Fix building test tst-strtod-round for ARM.
There was no rationale given for the change to fix bz#737223 and the
fix was never even proposed upstream. This patch causes a test
failure in the glibc testsuite. Revert the patch for now and do a
proper documented analysis if this actually results in any kind of
failure.
build-locale-archive was switched to link dynamically in 538b3c08
without giving a proper reason for it. The earlier static build was
wrong though, since it would happen against the installed glibc and
not the glibc being built. The dynamic link was also similarly wrong,
more so because it would build against the built libc.so.6 and then
try to load the system libc.so.6. This results in a failure in %post
in cases when the new build-locale-archive may have symbol references
that are not present in the old glibc.
There seem to be no good reason to run build-locale-archive with the
system libc.so.6, so the change is now reverted with a fixed up static
link that links against the build static libc.a.
