Upstream commit: 0cd4a5e87f6885a2f15fe8e7eb7378d010cdb606
- sunrpc: Remove stray exports (#1577210)
- gd_GB: Fix typo in abbreviated May (swbz#23152)
- realpath: Fix path length overflow (swbz#22786)
- elf: Fix stack overflow with huge PT_NOTE segment (swbz#20419)
- resolv: Fully initialize struct mmsghdr in send_dg (swbz#23037)
- manual: Various fixes to the mbstouwcs example, and mbrtowc update
- getlogin_r: return early when linux sentinel value is set
- resolv: Fix crash in resolver on memory allocation failure (swbz#23005)
- Fix signed integer overflow in random_r (swbz#17343)
- RISC-V: fix struct kernel_sigaction to match the kernel version (swbz#23069)
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 d43610c362.
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
Upstream commit: 4612268a0ad8e3409d8ce2314dd2dd8ee0af5269
- Correct the list of static PIE architectures
- glibc_post_upgrade: Remove process restart logic
- glibc_post_upgrade: Integrate into the build process
- glibc_post_upgrade: Do not clean up tls subdirectories
- glibc_post_upgrade: Drop ia64 support
- Remove architecture-specific symbolic link for iconvconfig
- powerpc: Fix syscalls during early process initialization (swbz#22685)
This gives us access to the relevant definitions and also enables
us to perform a static PIE build without replicate the entire
compiler invocation.
Due to the move into the glibc build process, the program had to
be cleaned up to compile without warnings.
Its purpose is not entirely clear. glibc_post_upgrade invokes
iconvconfig with explicit paths, so it does not matter for which
multilib variant the binary was built.
