Re: __memcpy_chk family of functions
- Reply: Marcin Cieslak : "Re: __memcpy_chk family of functions"
- In reply to: Dag-Erling_Smørgrav : "Re: __memcpy_chk family of functions"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Tue, 21 May 2024 13:20:09 UTC
On Tue, May 21, 2024 at 12:16 AM Dag-Erling Smørgrav <des@freebsd.org> wrote: > Marcin Cieslak <saper@saper.info> writes: > > I have updated some binary packages using pkg(8) but neglected to > > rebuild the world and my favourite web browsers no longer started > > complaining about the undefined symbol __memcpy_chk@FBSD_1.8 > > > > Would that be a good idea to add that information to the Handbook and > > possible bump FreeBSD_version and add this info to UPDATING? > > The purpose of UPDATING is to document changes that break backward > compatibility, i.e. running old binaries on a newer world. What > happened here is that you tried to run newer binaries on an older world, > an issue of _forward_ compatibility, which we've never promised. > Besides, an entry in UPDATING wouldn't have helped you since your source > tree predated the change that would have added it. > Also, our forward compatibility guarantees are extremely weak. At most the outer bounds are around a sliding window to upgrade from source, using root in single user on the console. So having to revert to an old kernel to build a new kernel when there's a problem, or having to revert to an old kernel to rebuild old sources. And even then it's not something we test, so it's likely broken or broken once you get a hair's width away from that path. Plus, with BEs and the easy ability to roll back to the prior BE, even this level of forward compat is likely to decay further in the future. Warner