The file list geneation for the main package and subpackages was
unorganized and poorly structured. With this commit we change this
in three siginifcant ways:
* All file lists are built independent of each other from a master
list of files e.g. rpm.list. This is the important cleanup.
* All files are installed into %{glibc_sysroot}, which defaults
to $RPM_BUILD_ROOT. This supports future experimentation with
alternate glibc installs via this new variable.
* Redundant code is removed which is no longer required, like the
debuginfo list de-duplication; simplifying the install process.
The changes were tested by carrying out a file-by-file comparison
to ensure no file changed packages or installed location after
the patch.
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.
No ABI instrumentation is added by this patch, and before-and-after
testing verifies the %install phase remains functionally the same.
Upstream commit: 93304f5f7a32f73b551266c5a181db51d97a71e4
- Install <bits/statx.h> header
- Put the correct Unicode version number 11.0.0 into the generated files
Upstream commit: fd70af45528d59a00eb3190ef6706cb299488fcd
- Add the statx function
- regexec: Fix off-by-one bug in weight comparison (#1582229)
- nss_files: Fix re-reading of long lines (swbz#18991)
- aarch64: add HWCAP_ATOMICS to HWCAP_IMPORTANT
- aarch64: Remove HWCAP_CPUID from HWCAP_IMPORTANT
- conform/conformtest.pl: Escape literal braces in regular expressions
- x86: Use AVX_Fast_Unaligned_Load from Zen onwards.
CFLAGS is not generally used when calling assembler, and this eventually
exposes a design issue in the annobin notes handling; see bug 1576362.
This reverts commit 7c1047805b.
The following commit removes the requirement for patches to be
placed in 1000, 2000, or 3000 ID blocks depending on their
upstream status. Instead upstream status is documented in the
header of the patch with some semi-standard notation as described
in template.patch. The patches are re-numbered and defined and
applied in the same order. Verified that before and after the
patch that the source tree does not change. The patch definition
is resorted to match the patch application order.
glibc-common already depends on /bin/sh, so it would be installed at a
time when trigger runs.
Signed-off-by: Igor Gnatenko <ignatenkobrain@fedoraproject.org>
not supported even by GCC 7.3.1 on this architecture.
Apparently it requires architecture-specific support. In any case it
does not work with GCC 7.3.1 on riscv64:
stage3:/# gcc --version
gcc (GCC) 7.3.1 20180129
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
stage3:/# gcc -fstack-clash-protection
gcc: error: unrecognized command line option '-fstack-clash-protection'; did you mean '-fstack-protector'?
gcc: fatal error: no input files
compilation terminated.
Since time immemorial, Red Hat/Fedora packagers have been required
to add a stanza to spec files for packages containing libraries to
update the ldconfig cache.
```
%post -p /sbin/ldconfig
%postun -p /sbin/ldconfig
```
To say this is annoying is to put it mildly. However, there was no
standard mechanism to make this boilerplate go away. Now with RPM 4.13+,
we should change this to file triggers and make all of that go away.
In the case of the transaction file triggers that run on the regular
link library paths, the performance benefit is minimal, and being greedy
does not hurt in this case. It's still an improvement over running
ldconfig every time anyway.
With the introduction of these triggers, we can start removing the
ldconfig boilerplate from Fedora package specs, and new packages will
not need to add it.
Pirority (-P) is not strictly needed, but we want to run our ldconfig
"first" before rest of scriptlets so it would speed up them (we would
build ldconfig cache beforehand).
References: https://bugzilla.redhat.com/1380878
Originally-proposed-by: Neal Gompa <ngompa13@gmail.com>
Signed-off-by: Igor Gnatenko <ignatenkobrain@fedoraproject.org>
Add applicable Requires on libxcrypt
Back in June, Björn Esser proposed to add OpenBSD-compatible bcrypt
support to our implementation of crypt(3), and Zack Weinberg replied
that it might actually make more sense to _remove_ libcrypt from
glibc, freeing up libcrypt.so.1 and crypt.h to be provided by a
separate project that could move faster. (For instance, libxcrypt:
https://github.com/besser82/libxcrypt)
This commit is the glibc part of:
https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt
