Re: __memcpy_chk family of functions
Marcin Cieslak writes: > Dag-Erling Smørgrav writes: > > Marcin Cieslak writes: > > > I think this (useful) change should go into the future release > > > notes as a new feature. > > Which change? > https://reviews.freebsd.org/D32306 Import _FORTIFY_SOURCE > implementation from NetBSD which introduced _memcpy_chk and friends to > our libc. See commit 9bfd3b4076a7 which has “Relnotes: yes”. It will be added to the 15.0 release notes in due time, possibly 14.2 as well if Kyle decides to merge it. DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: __memcpy_chk family of functions
On Tue, 21 May 2024, Dag-Erling Smørgrav wrote: Marcin Cieslak writes: I think this (useful) change should go into the future release notes as a new feature. Which change? https://reviews.freebsd.org/D32306 Import _FORTIFY_SOURCE implementation from NetBSD which introduced _memcpy_chk and friends to our libc.
Re: __memcpy_chk family of functions
Marcin Cieslak writes: > I think this (useful) change should go into the future release notes > as a new feature. Which change? DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: __memcpy_chk family of functions
On Tue, May 21, 2024 at 12:16 AM Dag-Erling Smørgrav wrote: The purpose of UPDATING is to document changes that break backward compatibility, i.e. running old binaries on a newer world. happened here is that you tried to run newer binaries on an older world, On Tue, 21 May 2024, Warner Losh wrote: Also, our forward compatibility guarantees are extremely weak. Just for clarification: I am not complaining about my breakage. It was my stunt and it didn't work out, I got punished by sitting there and waiting for llvm to compile. I think this (useful) change should go into the future release notes as a new feature. Where and how should this be documented? Shall FreeBSD_version be bumped for this one? For example, when libsys got introduced, we could learn about this from the UPDATING file. I do not want UPDATING to be come unreadable or a copy of git log, though. Marcin
Re: __memcpy_chk family of functions
On Tue, May 21, 2024 at 12:16 AM Dag-Erling Smørgrav wrote: > Marcin Cieslak 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
Re: __memcpy_chk family of functions
Marcin Cieslak 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. DES -- Dag-Erling Smørgrav - d...@freebsd.org
