On 06/13/2016 07:09 AM, Florian Weimer wrote:
glibc upstream, during development of the 2.24 release, introduced new
symbol versions recvmsg@GLIBC_2.24, sendmsg@GLIBC_2.24 (and
recvmmsg@GLIBC_2.24, sendmmsg@GLIBC_2.24 on 64-bit architectures), in
order to fix some minor POSIX compliance issue. (POSIX and the Linux
kernel disagree about the width of some fields in struct msghdr.) These
changes landed in rawhide as part of glibc-2.23.90-19.fc25.
This change caused quite a few issues (chrony stopped building, Address
Sanitizer interception of these functions was affected, probably more).
Considering that the deviation from POSIX was really minor, this was
considered a poor trade-off, and the patch and ABI change was eventually
reverted upstream.
We cannot implement the ABI reversal immediately in rawhide because that
would break existing binaries, and we don't want to do a bootstrap or
mass rebuild for this. Therefore, glibc-2.23.90-21.fc25 turns the new
symbols into compatibility symbols. As a result, new binaries will be
linked against the old symbol versions, as before, and old binaries
continue to work.
I have removed the compatibility symbols from rawhide, after all the
necessary rebuilds happened on primary. I double-checked aarch64,
ppc64, ppc64le, s390x as well and asked for additional rebuilds where
appropriate. (Some packages were built against different glibc versions
than on primary.) As a result, except on ppc64/ppc64le, all compat
symbol references are gone from the build root. ppc64/ppc64le current
has unrelated issues and falls farther and farther beyond primary, which
is why I didn't want to delay the compat removal (and alignment with the
glibc upstream ABI) until ppc64/ppc64le catches up eventually. I do not
expect any problems as long as rebuilds happen roughly in the order they
happened on primary.
Symptoms of an issue related to the compat symbol removal include error
messages about undefined GLIBC_2.24 symbols, particularly sendmsg,
sendmmsg, recvmsg, recvmmsg. RPM dependencies do not express this
information because they are not sufficiently fine-grained.
Florian
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org