Date: Wed, 31 May 2023 11:06:54 +0200 From: Dimitry Andric <dim@FreeBSD.org> To: Enji Cooper <yaneurabeya@gmail.com> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: "make hierarchy" from main tree breaks c++ headers on older branches with unclear errors if "make install world" is interrupted Message-ID: <8CD00413-E6B3-4DBA-8A71-CAFA647DF2FF@FreeBSD.org> In-Reply-To: <FDF6450A-7BE8-432D-822B-46B1BC475BB2@gmail.com> References: <E94D1471-8CDC-4AC3-A46B-C22922864637@gmail.com> <0DA92266-62F8-439E-9C56-44106A6B0073@FreeBSD.org> <FDF6450A-7BE8-432D-822B-46B1BC475BB2@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_4608D242-A0FB-4C83-BF73-C11493593DAA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 31 May 2023, at 01:07, Enji Cooper <yaneurabeya@gmail.com> wrote: >=20 >> On May 28, 2023, at 3:53 AM, Dimitry Andric <dim@FreeBSD.org> wrote: >> On 28 May 2023, at 07:18, Enji Cooper <yaneurabeya@gmail.com> wrote: >>>=20 >>> I just tried to run =E2=80=9Cmake hierarchy=E2=80=9D from a main = tree on a 13.2-RELEASE system, and doing so completely broke my headers. >>> It took me about 30 minutes to figure out what happened=E2=80=A6 = /usr/include/c++/v1/__string was a header, whereas on :main it=E2=80=99s = a directory?! >>=20 >> Yes, upstream libc++ has split up large headers into multiple = components, in particular __string and __type_traits. >>=20 >> Since we had a file named __string, it had to be somehow replaced by = a directory. This is what the distrib-cleanup target in the top-level = Makefile does: >>=20 >> https://github.com/DimitryAndric/freebsd-src/commit/6b13b4a095e3 >>=20 >> Afterwards, the replacement directory named __string is created as = part of the regular mtree commands. >>=20 >>=20 >> ... >>> I reinstalled the headers by going to lib/libc++ in my releng/13.2 = tree, building, and installing all of the 13.2-RELEASE headers. >>> This change has been live for almost a year now on :main =E2=80=94 = is this a known caveat when doing a source-based upgrade from = 13.2-RELEASE* to 14.0-CURRENT, i.e., that the installworld (if = interrupted) could break the c++ compiler? >>=20 >> I think it should already be quite clear that interrupting = installworld is risky. If you were just in the middle of replacing libc = or rtld, and those were half-written, your system will be completely = hosed. (I am speaking from experience. :) The same goes for any system = headers or libraries, not only the C++ ones. If you have a = half-installed tree, it should not be used for anything except = attempting another installworld. >=20 > That=E2=80=99s a fair point, however, given that this follows the = standard installation workflow=E2=80=A6 > 1. etcupdate pre-run. > 2. install kernel > 3. reboot > 4. make installworld > 5. etcupdate post-run > =E2=80=A6 this could surprise end-users. In particular, the C++ = compiler will be broken between step 1 and step 4. How so? The deletion of the old __string file is done as part of = installworld, i.e. in step 4, not in any of the earlier steps. The only = case where you can have problems is when you start installworld, let it = run until it has completed its distrib-cleanup target, and then = interrupt it before it can install the new headers. -Dimitry --Apple-Mail=_4608D242-A0FB-4C83-BF73-C11493593DAA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCZHcOLgAKCRCwXqMKLiCW o5q1AJ0fT55YKDi0rZXKU1I/I+wJjp8Z7QCgkm+b/IZs0WPBSoXWNm4IcMpLsL4= =sBDQ -----END PGP SIGNATURE----- --Apple-Mail=_4608D242-A0FB-4C83-BF73-C11493593DAA--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8CD00413-E6B3-4DBA-8A71-CAFA647DF2FF>