From Fedora Project Wiki

glibc32 Build Adjustments

Summary

The glibc32 package is a special package used by gcc and a few other packages to work around the lack of RPM multilib repository support in Koji. It is difficult to maintain, and the current approach raises questions regarding (L)GPL compliance.

Owner

Current status


Detailed Description

Some packages build non-64-bit code on 64-bit architectures, using GCC switches such as -m32 and -m31. Those that do not use -nostdlib at the same time need a non-64-bit glibc as well. However, Koji cannot currently provide such multilib RPMs; all RPM packages are either of the build architecture or noarch packages.

In particular, GCC has a dependency on the non-64-bit (32-bit or 31-bit) glibc library.

The current hack to support GCC's need (and a few other packages) is that a separate package, glibc32, contains pre-built 32-bit/31-bit binaries extracted from RPMs built in Fedora some time in the past. Since these binaries are pre-built, they can be built (actually copied around) on any architecture, including the relevant 64-bit architectures.

This primarily affects the x86_64 architecture and its i686 multilib RPMs. Historically, the same problem occurred on ppc64 (with ppc as the multilib architecture) and s390x (with s390). However, Fedora no longer builds non-64-bit RPM packages on these architectures. This also means that the ppc and s390 binaries in the glibc32 package can no longer be recreated within Fedora, which is not sustainable. At the very least, these two sets of binaries would have to be removed, effectively making the glibc32 package specific to the x86_64 architecture.

It appears that on ppc64 we still need to build GCC in such a way that the -m32 option is supported. This means that some cross-package coordination is necessary. (A first check showed that the s390x boot loader support is built as 64-bit binary, so -m31 support in glibc does not seem to be necessary for bootloader purposes.)

There are two ways to address these problems:

  • Continue the current copy-based approach. It is simplified somewhat due to the switch to libxcrypt. Modify the (fully manual) extraction procedure so that the source RPM of the binary files is included as well, to provide airtight LGPL compliance.
  • Build glibc32 and libgcc32 subpackages from the glibc and gcc packages, which are then filtered by pungi from all composes. (Currently, the buildroot-only nature of glibc32 is achieved by tagging builds appropriately in Koji, which is rather fragile.) The big advantage of this approach is that the glibc32 package will always be in sync with the actual 64-bit library.

Benefit to Fedora

The glibc32 package will be fully (L)GPL-compliant, and if the second approach is chosen, its build procedure will be fully controlled by Koji, enhancing the conceptual (not bitwise) reproducibility of the build.

Scope

  • Proposal owners:
    • Drop ppc and s390 RPM contents from glibc32. Adapt the build procedure as agreed.
  • Other developers:
    • Fedora GCC developers will need to drop the build dependency on /usr/lib/libc.so on ppc64 and s390x. It may be necessary to configure GCC with --enable-targets=all, to support -m32 for building boot loaders and other freestanding code.
    • The compat-gcc-* and ghdl packages may need similar adjustments.
    • Other packages with a /usr/lib/libc.so.6 build dependency (chromium, systemtap, valgrind) appear to restricted to x86_64 already.
    • If the filtered subpackage approach is chosen for Fedora 29, the gcc package will need to be updated to build a new subpackage, libgcc32, that contains the multilib libraries. These will be required for building glibc32 as a subpackage.
  • Policies and guidelines: N/A (not a System Wide Change)
  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

The glibc32 package does not ship as part of any deliverable, so there is no upgrade or compatibility impact.

How To Test

N/A (not a System Wide Change)

User Experience

Users who currenctly rely on a working -m31 option on s390x may have to switch to a proper s390 cross-toolchain.

Dependencies

N/A (not a System Wide Change)

Contingency Plan

  • Contingency mechanism: We will keep the copying approach. If everything else fails, we keep the historic ppc and s390 binaries, but also add source RPMs. This can even be applied retroactively (because the build output of glibc32 is not impacted by this).
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? N/A (not a System Wide Change)
  • Blocks product? No.

Documentation

N/A (not a System Wide Change)

Release Notes

Since this affects only an internal buildroot-component, no release not is necessary (as long as we keep -m32/-m31 support in GCC).

Retrieved from "https://fedoraproject.org/w/index.php?title=Changes/glibc32_Build_Adjustments&oldid=676647"