Bug 7224 - glibc in build system is older than our requirement
Summary: glibc in build system is older than our requirement
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Build system (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.10.0
Assignee: Pierre Ossman
Keywords: ossman_tester, prosaic
Depends on:
Blocks: 5241
  Show dependency treegraph
Reported: 2018-08-15 12:45 CEST by Peter Åstrand
Modified: 2018-09-13 16:02 CEST (History)
1 user (show)

See Also:
Acceptance Criteria:
* glibc version for all archs should be the same as our documented requirements * Jenkins rebuild of cenbuild should work * workarounds for old glibc versions should be removed


Description Peter Åstrand cendio 2018-08-15 12:45:14 CEST
On bug 5754, we raised the glibc requirement to 2.12. However, we didn't actually change anything in our build system, which uses several old versions:


Motivation for upgrade:

1) To avoid that we are using different glibc versions on different platforms. We could use 2.12 on all.

2) As mentioned on bug 5754, "It will probably also solve various minor annoyances", which might mean getting rid of workarounds we have today.

3) Reduce the risk of subtle bugs and reduced functionality - we are using a glibc version which is no longer common.

4) Performance. If we just consider x86_64, these performance related enhancements are listed between 2.5 and 2.12:

* New optimized string functions for x86-64: strstr, strcasestr, memcmp,
  strcspn, strpbrk, strspn, strcpy, stpcpy, strncpy, strcmp (SSE2, SSE4.2),
  strncmp (SSE2, SSE4.2), strchr (SSE4.2), strrchr (SSE4.2).
  Contributed by H.J. Lu.

  strlen, rawmemchr, strcmp (SSSE3), strncmp (SSSE3).
  Implemented by Ulrich Drepper.

* Faster strlen, strchr, strchrnul, strrchr, memchr, and rawmemchr for x86-64.
  Implemented by Ulrich Drepper.

* New implementation of memmem, strstr, and strcasestr which is O(n).
  Implemented by Eric Blake.

* Faster memset for x86-64.

On one hand, for functions which does not change ABI (does not use symbol versioning) and are not inlined, one "should" get the performance improvement just by using a modern glibc at runtime. It does not matter that old headers are used. However, apparently inlined functions are sometimes used. From https://sourceware.org/glibc/wiki/FAQ#I.27ve_got_errors_compiling_code_that_uses_certain_string_functions.__Why.3F:

glibc has special string functions that are faster than the normal library functions. Some of the functions are additionally implemented as inline functions and others as macros. This might lead to problems with existing codes but it is explicitly allowed by ISO C.

The optimized string functions are only used when compiling with optimizations (-O1 or higher).
Comment 12 Karl Mikaelsson cendio 2018-09-10 09:38:28 CEST
Jenkins builds are passing again.
Comment 13 Karl Mikaelsson cendio 2018-09-10 09:40:04 CEST
r33650 fixed the cdrtools build, which falled apart with a high number of make jobs.
Comment 14 Pierre Ossman cendio 2018-09-13 16:02:27 CEST
> * glibc version for all archs should be the same as our documented requirements

We do indeed run glibc 2.12.2 everywhere.

(The requirement is for 2.12.0, but 2.12.2 is the same ABI, but with some internal bug fixes.)

> * Jenkins rebuild of cenbuild should work


> * workarounds for old glibc versions should be removed

I can not find any references to workarounds for glibc.

Note You need to log in before you can comment on or make changes to this bug.