Bug 8368 - Upgrade glibc
Summary: Upgrade glibc
Status: NEW
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Build system (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: LowPrio
Assignee: Bugzilla mail exporter
URL:
Keywords:
Depends on:
Blocks: 8361
  Show dependency treegraph
 
Reported: 2024-06-19 10:00 CEST by Joel Leesment
Modified: 2024-07-04 09:45 CEST (History)
1 user (show)

See Also:
Acceptance Criteria:


Attachments

Description Joel Leesment cendio 2024-06-19 10:00:41 CEST
We need to upgrade our glibc in cenbuild for the gcc dependency bug 8361
Comment 1 Joel Leesment cendio 2024-06-20 14:48:15 CEST
Did some research about what would be a good target version for glibc by looking up common distros and the version of glibc/libc6 they use. 
The table is a bit hard to read thanks to the formatting but each distro is listed with their version number and where it was sourced from.

| Distro          | Version   | Notes                                                                                                                                           |
| --------------- | --------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
| RHEL8           | 2.28      | https://access.redhat.com/solutions/38634                                                                                                       |
| RHEL9           | 2.34      | See above                                                                                                                                       |
| Ubuntu 20.04    | 2.31      | https://releases.ubuntu.com/focal/                                                                                                              |
| SLES15 SP5      | 2.31      | https://scc.suse.com/packages?name=SUSE%20Linux%20Enterprise%20Server&version=15.5&arch=x86_64&query=glibc&module=                              |
| SLES15 SP6      | 2.38      | Currently in beta - see above                                                                                                                   |
| Debian 11       | 2.31      | https://packages.debian.org/bullseye/libs/ - called libc6                                                                                       |
| Debian 12       | 2.36      | https://packages.debian.org/bookworm/libs/ - called libc6                                                                                       |
| Raspberry Pi OS | 2.31/2.36 | https://www.raspberrypi.com/documentation/computers/os.html - Debian derivatives                                                                |
| Arch            | latest(?) | Rolling-release model - An Arch Linux installation is kept up-to-date by regularly updating the individual pieces of software that it comprises |
| Gentoo          | ?         | Arcane magic and witchcraft     

From my findings glibc version **2.28** seems to be the highest possible version to support as many different distros as possible.
Comment 2 Samuel Mannehed cendio 2024-06-25 15:58:56 CEST
The glibc version we build with must be compatible with the glibc version on the Linux machine that runs our software. This applies to both the client and the server.
Comment 3 Joel Leesment cendio 2024-07-04 09:45:46 CEST
Started implementing the upgrade to glibc 2.28, this led to a chain reaction of dependencies breaking. Due to the nature of building cenbuild the order of architectures being built differs so the  problems arising can be a bit different depending on the architecture that gets built.

When attempting to rebuild glibc it complained that it requires kernel-headers >= 3.2.0, I opted to lift the current kernel-headers version from 2.6.34.1 all the way to 4.18 since that is what the host machine runs. (RHEL8).

In glibc 2.28 there were some major changes:
https://sourceware.org/legacy-ml/libc-alpha/2018-08/msg00003.html

ustat has been deprecated in favor of statfs and statfs this lead to lifting gcc from 5.5.0 to 8.5.0, where the patch has already been implemented and this is the version that the host machine runs.
(Fix was implemented here: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=71b55d45e4304f5e2e98ac30473c581f58fc486b)

The header <libio.h> is deprecated in favor of <stdio.h>, when writing this message the following packages (previous version -> upgraded / fixed version) were broken:
gzip 1.3.13 -> 1.10
findutils 4.4.0 -> 4.7.0
m4 1.4.16 -> 1.419
All packages had the same fix: https://github.com/coreutils/gnulib/commit/4af4a4a71827c0bc5e0ec67af23edef4f15cee8e.patch
(Versions to upgrade to were determined by checking each package using https://src.fedoraproject.org/projects/rpms/%2A as it served as a reference to see what version of a package that no longer needed the patch.)

Another thing in glibc 2.28 is that the major, minor and makedev macros are now only available from the header <sys/sysmacros.h> and not from <sys/types.h> or various other headers that happen to include <sys/types.h>.
See:  https://sourceware.org/bugzilla/show_bug.cgi?id=19239 

This change broke util-linux so I lifted the version from 2.19.1 to 2.32.1 to match the host machine. 

NOTE: This causes a conflict between util-linux and coreutils where the utility kill and the corresponding man-page causes the conflict. I opted to delete both the man-page and the /bin/kill in the util-linux.spec file.

Currently investigating the breakage of Make, Linux-PAM, glib2.

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