glibc March 2018

glibc@lists.fedoraproject.org

2 participants
5 discussions

Source RPM size
by Florian Weimer 15 May '18

15 May '18

Would it concern you if the source RPM size grew to about 110 MiB? This data would not have to be uploaded with a “fedpkg new-sources” command for every upstream import, only once per Fedora release cycle. Thanks, Florian

2 14

tarballs vs ABI xml files in dist-git.
by Carlos O'Donell 14 May '18

14 May '18

Florian, You expressed some worry about checking in the tarballs for the frozen ABI specification into dist-git. Really git is not designed to hold tarballs, and the source cache is just wrong since this is not a source tarball (we used to abuse it also for the releng tarball). It is relatively easy to move all the files directly into dist-git, and use a lua construct like this: +%{lua: +-- List all of the frozen ABI xml files as source files. +function recursedir(directory) + local i, t, popen = 0, {}, io.popen + local pfile = popen('find "'..directory..'" -type f') + for filename in pfile:lines() do + i = i + 1 + t[i] = filename + end + pfile:close() + return t +end +# There are almost 2000 ABI specification files. +lines = recursedir ('releng/frozen-abi/') +-- Last Source file is numbered 12. +j = 12 +for i,v in ipairs(lines) do + print('Source'..i..': '..v) + j = j + 1 +end +} +%endif Which generates the source line entries from the directories. This would allow us to manually tweak the ABI files by hand and track the changes over time as we update glibc. Would this be a better design? -- Cheers, Carlos.

3 14

[PATCH 2/2] Add formal ABI verification for all shared objects.
by Carlos O'Donell 01 Mar '18

01 Mar '18

The spec file is enhanced to allow a developer to save (save_abi=1) the ABI of the package, and to turn on verification of the ABI (verify_abi=1). The saved and manually inspected ABI for aarch64, armv7hl, i686, ppc64, ppc64le, s390x, and x86_64 are also checked in as compressed archives. When a release branch is in effect (without the .9000 subrevision) the spec file automatically turns ABI verification on and compares, during the install phase, the generated ABI of the installed shared objects before stripping. Carrying out the ABI verification at this point yields the highest quality debug information, and least likelihood of problems. It is expected that the distribution will do it's own rpm to rpm checking. This ABI checking is meant as a glibc developer tool to assist in catching ABI changes before deployment. --- frozen-abi-aarch64.tar.xz | Bin 0 -> 235400 bytes frozen-abi-armv7hl.tar.xz | Bin 0 -> 234312 bytes frozen-abi-i686.tar.xz | Bin 0 -> 246472 bytes frozen-abi-ppc64.tar.xz | Bin 0 -> 242444 bytes frozen-abi-ppc64le.tar.xz | Bin 0 -> 242624 bytes frozen-abi-s390x.tar.xz | Bin 0 -> 241872 bytes frozen-abi-x86_64.tar.xz | Bin 0 -> 240508 bytes glibc.spec | 183 ++++++++++++++++++++++++++++++++++++++++++++++ 8 files changed, 183 insertions(+) create mode 100644 frozen-abi-aarch64.tar.xz create mode 100644 frozen-abi-armv7hl.tar.xz create mode 100644 frozen-abi-i686.tar.xz create mode 100644 frozen-abi-ppc64.tar.xz create mode 100644 frozen-abi-ppc64le.tar.xz create mode 100644 frozen-abi-s390x.tar.xz create mode 100644 frozen-abi-x86_64.tar.xz Note: I would like to backport this to F28 if accepted for Rawhide. -- Cheers, Carlos.

1 0

[PATCH 1/2] Reorganize %install phase.
by Carlos O'Donell 01 Mar '18

01 Mar '18

The %install phase is reorganized into 3 distinct phases, the first phase where files are modified, a second phase where file lists are generated, and a final phase where files are only removed based on list information. This cleanup makes it very clear when we are done installing files, and therefore creates a place where we can put ABI instrumentation to compare the resulting ABI before stripping and debuginfo generation. --- glibc.spec | 241 ++++++++++++++++++++++++++++++------------------------------- 1 file changed, 120 insertions(+), 121 deletions(-) -- Cheers, Carlos.

1 0

[PATCH 0/2] Implement strict ABI checking for glibc.
by Carlos O'Donell 01 Mar '18

01 Mar '18

Fedora glibc team, In the "Platform Interface" document [1] I talk about a distribution in which there is a distinction between what you run against and what you compile against. I had originally designed a new sysroot-glibc package which would be installed by default, and all applications would compile against that. However, in hindsight this is backwards to what users want. They key benefit I wanted was a bullet-proof way to avoid ABI breaks by using tooling. This would also help lower the bar for less senior developers contributing without the fear they would break the ABI. Consensus is that the normal day-to-day compilation against libraries like glibc should *not* change, and it should remain the normal process. Only users that want the newer glibc should have to add things to their build flags to link with a newer glibc. Likewise the newer glibc should be deployed as either a distinct package or in a distinct repository with the required packaging changes (provides all of it's interfaces in a sysroot, and a replacement runtime). If you are going to use the new glibc for compiling against then you must also install the new glibc for runtime. That is to say we support upgrading the development environment, but we do not support distinct cross-compilation (difficult to do without a lot of coordination on --prefix=/usr installed runtime data like locales, caches, etc). Therefore since I plan to retain a system glibc default installation that installation could benefit from more robust ABI checking, like we *would* have had if we compiled against a sysroot for the system glibc. The following two patches do just that. Patch 1/2 cleans up the glibc %install phase. Patch 2/2 introduces a process to record the ABI for all shared libraries, and then use that frozen ABI record to verify the ABI in great detail. This ABI checking is beyond what glibc does with *.abilist checking, and closer to what distributions are doing with their package release process (not yet standardized). Perhaps we will move this upstream one day when we've had more experience with it in Fedora. We currently rely on libabigail for ABI serialization. -- Cheers, Carlos. [1] https://fedoraproject.org/wiki/PlatformInterface

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

glibc March 2018