F29 Self Contained Change: glibc 32 Build Adjustments
= 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