= Proposed Self Contained Change: glibc 32 Build Adjustments = https://fedoraproject.org/wiki/Changes/glibc32_Build_Adjustments Owner(s): * Florian Weimer <fweimer at redhat dot com> 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 [https://pagure.io/koji/issue/273]. It is difficult to maintain, and the current approach raises questions regarding (L)GPL compliance. == 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 [https://pagure.io/releng/issue/7576]. (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. == 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. * Release engineering: #7578 [https://pagure.io/releng/issue/7578] ** List of deliverables: N/A (not a System Wide Change) * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) -- Jan Kuřík JBoss EAP Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/SBGG4BZDJ4N2J33U5QCFNDS2NN4K2HQB/
