Date: Tue, 30 May 2023 16:07:42 -0700 From: Enji Cooper <yaneurabeya@gmail.com> To: Dimitry Andric <dim@FreeBSD.org> 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: <FDF6450A-7BE8-432D-822B-46B1BC475BB2@gmail.com> In-Reply-To: <0DA92266-62F8-439E-9C56-44106A6B0073@FreeBSD.org> References: <E94D1471-8CDC-4AC3-A46B-C22922864637@gmail.com> <0DA92266-62F8-439E-9C56-44106A6B0073@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_CDECEF28-D00E-4847-8D23-755F608C0AA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 28, 2023, at 3:53 AM, Dimitry Andric <dim@FreeBSD.org> wrote: >=20 > 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. 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. It would be good to bring this fact up in UPDATING or RELNOTES as a = warning because it could result in a broken system that=E2=80=99s = difficult to recover from. Cheers, -Enji --Apple-Mail=_CDECEF28-D00E-4847-8D23-755F608C0AA7 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----- iQIzBAEBCAAdFiEEtvtxN6kOllEF3nmX5JFNMZeDGN4FAmR2gb4ACgkQ5JFNMZeD GN6YnQ/+L3uTxKy4u7jOtZB8KoPi4wYCwUPVxp0j0vH7KcfPOoVl9o8QulDJ30DC shIR36AVqaywHE8RghIhiJ8TtSXr+/8feDAPMNPDlqkpAaLLEu/t/QjVDxlWBOeA 2Y9SIkN+a3MEW5O9NMVbXTktZgU14S9xFt+KzUITqvQLRI3XI23QslyVvksW1Lfo rzyMsKjtUN8f4l2XiTDDoVJl6TUDFkBDPDcSeIz3mgqfkrbVLhSXZG1g8rBa7MfM bU8mHawLQsjdPBfYzG5UFdeWZwMCWojlYPGwBUilzCYvt2571kcG3pdOvvnDAGDY utEvQTvUdNAEqMWqHiKP+B1AJW/zJze1VZrmGDcT+X3HjryIkATYnxauLMvQnonv FGdcdjZp/8SxwVWOS/S4QxLeRPgqtzy9jbJtpMqu0L/pGk2Tph3UKTbQH9CUzp1d MkMvrC8uA/oYWDXUqlF79Z4sSDa33rom2l+a4W51WK4HKLhIptLLaKzcyuhThEY1 5KHl2CYGVxah6XUry9kVnsGb/ZpQFkV1fafqfJhvJ+NFdeLUMc+QsSkXvBGfatI1 cpaBhUMMW7GEuwt9awlwIOazXoIf0Fu7CRVtnNrZO3HCbwfRAMeyOSpjMEbTgWs9 hNmaQI3YdK4bZyjjllXCbyHHtpjCyW6xcjSJyYYZAFA4lgCRu9E= =Zzqs -----END PGP SIGNATURE----- --Apple-Mail=_CDECEF28-D00E-4847-8D23-755F608C0AA7--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FDF6450A-7BE8-432D-822B-46B1BC475BB2>