We need to upgrade our glibc in cenbuild for the gcc dependency bug 8361
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.
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.
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.
## glibc - new requirement, new option glibc requires bison 2.7 since version 2.27. When building for armhf specifically the build really misbehaves, I don't know if I need to add that requirement to some other spec file or macro but its something about bison and install-locales that is not quite right. Seems to build just fine on the other architectures. NOTE: Added some code (crosscompiling checks) to bypass this error for now. Did some research about the --enable-kernel=x.y.z, changed it from 2.6 to 3.2. "This option is currently only useful on GNU/Linux systems. The version parameter should have the form X.Y.Z and describes the smallest version of the Linux kernel the generated library is expected to support. The higher the version number is, the less compatibility code is added, and the faster the code gets." - https://www.gnu.org/software/libc/manual/html_node/Configuring-and-compiling.html Since glibc 2.26 you need linux kernel 3.2 or later ( https://lists.gnu.org/archive/html/info-gnu/2017-08/msg00000.html ) Basing this on that our version of glibc (2.28) requires kernel-headers of at least version 3.2. Some reference of glibc and kernel combinations: - RHEL 6 (glibc 2.12, kernel 2.6.32) - RHEL 7 (glibc 2.17, kernel 3.10) - Fedora 29 (glibc 2.28, minimum kernel 3.2) - https://src.fedoraproject.org/rpms/glibc/blob/f29/f/glibc.spec#_249 - Centos 8 (glibc 2.28, minimum kernel 3.2) - https://git.centos.org/rpms/glibc/blob/c8/f/SPECS/glibc.spec#_1095 - SLES 11-SP4 (glibc 2.11.3, kernel 3.0.101) - SLES 12-SP5 (glibc 2.22, kernel 4.12.14) - Ubuntu 12.04 (glibc 2.15, kernel 3.2) - Ubuntu 14.04 (glibc 2.19, kernel 3.13) - Ubuntu 18.04 (glibc 2.27, minimum kernel 3.2) - https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/glibc/tree/debian/sysdeps/linux.mk?h=ubuntu%2Fbionic#n4 - Debian 7 (glibc 2.13, kernel 2.6.26) - Debian 8 (glibc 2.19, kernel 2.6.32) - Debian 9 (glibc 2.24, kernel 3.2) - Debian 10 (glibc 2.28, minimum kernel 3.2) - https://salsa.debian.org/glibc-team/glibc/-/blob/buster/debian/sysdeps/linux.mk?ref_type=heads#L4 - NixOS (glibc 2.27, minimum kernel 3.2) - https://github.com/NixOS/nixpkgs/blob/273e58ebd9f8ef04948a89d496c7cb23dab8cbe8/pkgs/development/libraries/glibc/common.nix#L114 ## bison - upgraded from 2.4 to 3.0.4 and patched. Glibc now requires bison 2.7 or higher since glibc 2.27, the intl subsystem generates a parser using bison. Upped the version to 3.0.4 (based on f29 and c8s) to match the host machine and patched to adjust for the glibc 2.28 libio.h removal. Patch based on this: https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blobdiff;f=lib/fseterr.c;h=adb637256dcf159a969045831926106ccf438faf;hp=82649c3ac1bf139dea7b2a7a6fc0832371a304c0;hb=4af4a4a71827c0;hpb=0404c9ae2845cbf93d71b295b67d6c8bd39382d8 --- ## make - Upgrading from 3.82 to 4.2.1 Encountered an error in glob.c where undefined reference to `__alloca` lifted make from 3.82 to 4.2.1 to match host system to see if it would help, it did not. Googled around and tried to find an answer and this is the closest to an answer I got: https://bug-make.gnu.narkive.com/OEO9TY5v/undefined-reference-to-alloca Wrote a patch and applied it and now it builds. Following patches relating to glob.c might be of relevance or help deciphering the problem/solution: https://src.fedoraproject.org/rpms/make/blob/f29/f/make-4.2.1-glob-fix.patch - 48c8a116a914a325a0497721f5d8b58d5bba34d4 (implemented here) https://src.fedoraproject.org/rpms/make/blob/f29/f/make-4.2.1-glob-fix-3.patch - 48c8a116a914a325a0497721f5d8b58d5bba34d4 (implemented here) NOTE: Someone with more experience might want to take a look if this (fix) breaks something down the line. --- ## glib2 - Upgrading from 2.34.3 to 2.56.4 + build requirement, --disable-libmount Encountered an error with glib2 where there were undefined references to minor and major, I reckon it is due from the change where minor, major and makedev can be found in <sys/sysmacros> now rather than <sys/types.h> in glibc 2.28, opted to lift the version number to match the host machine. The new version asks for PCRE with unicode support, added PCRE as requirement. glib2 asks for PCRE's shared libraries NOTE: arm specifically complains about not finding libmount, support for autotools libmount was added back in 2016 (2.49.4-19), commit: 4f9cddaeb8fc1b236ca49f08c1efa3fc9e75ecbf , the previous version of glib2 (2.34.3) was released in 2012. Added the flag --disable-libmount, figured that if you haven't been using it all this time I can build without it. ## pcre - new options Added the flags --enable-utf and --enable-unicode-properties since glib2 requires that. NOTE: In the PCRE.spec I added: export CFLAGS="$CFLAGS -fPIC", since it asks for that. --- ## Linux-PAM - upgrading from 1.1.0 to 1.3.1 pam complains about not finding rpcsvc/ypclnt.h, the RPC implementation in glibc is obsoleted. Programs in need of RPC functionality must be linked against TI-RPC. It was removed in glibc 2.14: See: https://abi-laboratory.pro/?view=changelog&l=glibc&v=2.14 git mirror: https://github.com/bminor/glibc/blob/master/NEWS#L5916-L5924 Upgrading to version 1.3.1 (same as host) and it seems to build fine. --- ## Pax With the magic of sed the missing <sys/sysmacros.h> is inserted into files affected by the change of headers in glibc. --- ## Pango - upgrading from 1.25.5 to 1.27.1 Encountered a problem where Pango 1.25.5 started complaining about flexible arrays in unions or a flexible array not in the end of a struct. Potential fix: https://gitlab.gnome.org/GNOME/pango/-/commit/29010456474a512c4193f2fec583c2723f3e2806 Lifted from version 1.25.5 to 1.27.1 as the patch was implemented in 1.26.2, seem to build this version fine. --- ## nss - upgrading from 3.12.4 to 3.47.1, reorganization When trying to build nss following error occurred : "BUILD/nss-3.12.4/mozilla/security/nss/cmd/shlibsign/./sign.sh: line 2: 2015223 Floating point exception(core dumped) ${2}/shlibsign -v -i ${5}" Lifted to version 3.47.1 to match fedora 29's rpm package. Now requires nspr, see information below. The file/directory name has changed, added some lua magic to extract the new file/directory name. There has been a (huge) reorganization of files. See changes in commit: bf65ba4ce1c2ff59a9677f07cbb50569ed1f5ba7 NOTE: For now I've just made sure that it builds at all, built without WINNTCROSS.mk - is it still needed? ## nspr - upgrading from 4.8 to 4.23 Needed to bump NSPR from 4.8 to 4.23 to match fedora 29's rpm package to get nss the correct headers. --- ## libiconv - upgrading 1.14 to 1.17 Encountered an error when linking: https://savannah.gnu.org/bugs/?47953 Upped the version to the latest, seems to build fine. --- ## Notes: Both osx and win32 architecture/components upgrades are put on hold because osx is moving towards clang solutions (https://bugzilla.cendio.com/show_bug.cgi?id=5878) and the possibility of win32 getting phased out with the transition to the .msix installer. In my previous comment I said that another change in glibc 2.28 was that the "major", "minor" and "makedev" headers are only available from <sys/sysmacros.h>, the mention of the (future) deprecation seem to have started in 2.25 (2017-02-05): https://lists.gnu.org/archive/html/info-gnu/2017-02/msg00002.html and actually deprecated in 2.28 (2018-08-01): https://lists.gnu.org/archive/html/info-gnu/2018-08/msg00000.html so this means that shortly after the 2.25 release there could be adjustments made for this change, if anyone needs to do some archaeological digging.
Work on upgrading glibc in MR !35 is all but done now. Cenbuild itself builds well in it's entirety, and it can build the ThinLinc server without issues. Only bug 8528 remains before we can merge !35 and close this bug, using cenbuild from !35 the ThinLinc Linux client doesnt build.
Note that with the below commit, the build time for glibc is heavily reduced: https://git.cendio.se/thinlinc/cenbuild/-/merge_requests/35/diffs?commit_id=597a23b272e52612231c57c51c2531a8a581c980 On my workstation I have seen differences of ~35 minutes -> 12 minutes. In jenkins builds the difference isn't as big.
One odd fallout is that tlstunnel fails to build after the upgrade: > gcc -Wall -O2 -g -g -o tlstunnel tlstunnel.o -Wl,-Bstatic -lgnutls -lhogweed -lnettle -lgmp -ltasn1 -lz -Wl,-Bdynamic -pthread > /usr/lib/gcc/x86_64-unknown-linux-gnu/5.5.0/../../../../lib64/libgnutls.a(libgnu_la-secure_getenv.o): In function `secure_getenv': > /local/home/aleze/git/cenbuild/repo/rpmbuild/BUILD/gnutls-3.8.7/gl/secure_getenv.c:32: undefined reference to `__secure_getenv' The issue is that __secure_getenv() got promoted to a standard secure_getenv() as part of the glibc upgrade. The old method is still included for already built applications, but they've managed to hide it from the compiler linker. A rebuild of GnuTLS should be sufficient to resolve it. But we might want to upgrade it at the same time.
Tested a build with an upgraded GLIBC, and everything seems to work well. Tested the server on RHEL 8 and RHEL 10 (beta), and the client on Fedora 41 and Raspberry Pi.
Everything should now be in place and working nicely. > MUST: > > * ThinLinc should be built against the latest GLIBC version that's available in all popular distributions Yes. RHEL 8 is the oldest with GLIBC 2.28, which is what we're now using. SLES 12 is soon EoL, so we're ignoring that. > * The new requirement should be clearly documented Should be. The TAG is updated, and this is mentioned in the release notes. > SHOULD: > > * Workarounds for older GLIBC that are no longer required should be removed from the cenbuild and ThinLinc source trees Fixed on thing in cenbuild, but could not find anything else in either cenbuild nor ThinLinc. I found a reference to execvpe() in the session startup that could be changed. But we also donated that code to TigerVNC, where we want to support other systems than Linux, so it might be easier to let them stay identical.
