Date: Tue, 21 May 2024 07:20:09 -0600 From: Warner Losh <imp@bsdimp.com> To: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= <des@freebsd.org> Cc: Marcin Cieslak <saper@saper.info>, current@freebsd.org Subject: Re: __memcpy_chk family of functions Message-ID: <CANCZdfrMYu5L4np%2B0kiAJCMOEugAgVeY0N5Tm%2B%2BOkFR8U9VY8Q@mail.gmail.com> In-Reply-To: <86msojvgfb.fsf@ltc.des.dev> References: <20qspnq2-8qp0-pq49-rq65-986n0q4r6rqq@fncre.vasb> <86msojvgfb.fsf@ltc.des.dev>
next in thread | previous in thread | raw e-mail | index | archive | help
--0000000000000ec7210618f6ae23 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, May 21, 2024 at 12:16=E2=80=AFAM Dag-Erling Sm=C3=B8rgrav <des@free= bsd.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 --0000000000000ec7210618f6ae23 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Tue, May 21, 2024 at 12:16=E2=80= =AFAM Dag-Erling Sm=C3=B8rgrav <<a href=3D"mailto:des@freebsd.org">des@f= reebsd.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style= =3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding= -left:1ex">Marcin Cieslak <<a href=3D"mailto:saper@saper.info" target=3D= "_blank">saper@saper.info</a>> writes:<br> > I have updated some binary packages using pkg(8) but neglected to<br> > rebuild the world and my favourite web browsers no longer started<br> > complaining about the undefined symbol __memcpy_chk@FBSD_1.8<br> ><br> > Would that be a good idea to add that information to the Handbook and<= br> > possible bump FreeBSD_version and add this info to UPDATING?<br> <br> The purpose of UPDATING is to document changes that break backward<br> compatibility, i.e. running old binaries on a newer world.=C2=A0 What<br> happened here is that you tried to run newer binaries on an older world,<br= > an issue of _forward_ compatibility, which we've never promised.<br> Besides, an entry in UPDATING wouldn't have helped you since your sourc= e<br> tree predated the change that would have added it.<br></blockquote><div><br= ></div><div>Also, our forward compatibility guarantees are extremely weak.= =C2=A0 At most the outer</div><div>bounds are around a sliding window to up= grade from source, using root in single user</div><div>on the console. So h= aving to revert to an old kernel to build a new kernel when there's</di= v><div>a problem, or having to revert to an old kernel to rebuild old sourc= es. And even then</div><div>it's not something we test, so it's lik= ely broken or broken once you get a hair's width</div><div>away from th= at path. Plus, with BEs and the easy ability to roll back to the prior BE,<= /div><div>even this level of forward compat is likely to decay further in t= he future.</div><div><br></div><div>Warner <br></div></div></div> --0000000000000ec7210618f6ae23--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrMYu5L4np%2B0kiAJCMOEugAgVeY0N5Tm%2B%2BOkFR8U9VY8Q>