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@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
