From nobody Mon Jul 29 14:54:56 2024 X-Original-To: freebsd-toolchain@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WXhGq1Vfgz5RPHL; Mon, 29 Jul 2024 14:54:59 +0000 (UTC) (envelope-from vishwin@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WXhGq0z61z4vwB; Mon, 29 Jul 2024 14:54:59 +0000 (UTC) (envelope-from vishwin@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1722264899; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=goAfZUtupcQ03OHnGHOKC/i4cSErRNMK14/S9MPCWXc=; b=j/uAVXfeoxf+lTnA7itx7B5tenJtmbNTGeSYuyXsgULZ52wi9ecQEDXMdK4M0gB7oT1e/K 9oHeoF1MeIpyn151j653kWrYzqH1J4Od7350lf9iinEe31CxJBFrp/nfVwjTfp+YIXgXvH nF75FFHD5B9nS+3pf8H/UWI+RCwNVy+maKVa1i7T1PLXrnS3MbWusWsh0q5g/kSPVcK59h 7LX2gZpSss47LfyTh1JMQEE2zCRvWO+L93LYi8OtBhdbHWi5/aIdseoQ+aHl8LWZrola9a kK1YkTbGbe+X54SDLckBRbapQKc90GTJQUnbAp71YTwW0F6Igxi7pqvBm9IFAQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1722264899; a=rsa-sha256; cv=none; b=nZmfjx9ljkTo+SGKol+NjPO/VNo6K60DtBpFPN0JauqZhYDm/biiVujnsrIzEmDdgczLxc W/qVHLfS7UZtAVj+p36t03tDr5MgXLHDV1RTmIoxdmfbCpywOBkd32AD3iIvGKiZs4XVEb uY1QSsT01jOkHA4yeV1Phph3DGMPEaBHUCe6slD1eMv0dhvaAumU3B5bYemMBp8+LVaVHw Oh13vSdHdAAHCVNpf4jocpGwUFgL9DeCId3MvjbUjPtanF58rjUVyw4aKuu9snlqig6NgB d1MvtW79nwFCxlj0AmvGzyz+r6qeTwPzRN5g+dulHSlztRGTPWAgxHxpejTPFw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1722264899; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=goAfZUtupcQ03OHnGHOKC/i4cSErRNMK14/S9MPCWXc=; b=tvnhaGb2JoH2KHNuejBAuO8BuuGBMQ25XtrPMnrvfUNdNWmMOK5AuO6Z150k+IPysvyHj4 ijD3gtH5UX64JN3Wch79JKu3qqAYbEk9neQ8RA07FIp0Iwr150YNNJLW3nEoKg6sT7blXJ 73ZE8QUg5CkEXvbxm77BHD2I1d2Hlxjuo1AMuTOOCFZYipmdAUXUJ/GE8gGQDAoAI567ru hVMaqUBSOrWvkjjmul1VTWmDfw/vGxsLy6tu8nmAiE/t72pV4iP21ZaMfOH2xt5k4S1pdf vwClBstOWdebfQdFfPV2qSjA94uuORzYRfUQo7ihYnNCcW/ITscQ9c8P3VCzuQ== Received: from [IPV6:2601:98a:d00:c180:56ee:75ff:fe50:69b5] (unknown [IPv6:2601:98a:d00:c180:56ee:75ff:fe50:69b5]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: vishwin/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4WXhGp6XFSz1Qjp; Mon, 29 Jul 2024 14:54:58 +0000 (UTC) (envelope-from vishwin@freebsd.org) Message-ID: <5ef8f532-e411-449e-9d0e-798ad9da3c3f@freebsd.org> Date: Mon, 29 Jul 2024 10:54:56 -0400 List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: FreeBSD libc++ , ports, and import std or import std.compat : what if potential ports start using them over time? To: Mark Millard , freebsd-arch Cc: FreeBSD Toolchain References: <87497F2F-8C4F-48C8-8737-979070B41C78.ref@yahoo.com> <87497F2F-8C4F-48C8-8737-979070B41C78@yahoo.com> Content-Language: en-GB From: Charlie Li Autocrypt: addr=vishwin@freebsd.org; keydata= xjMEZFWWqBYJKwYBBAHaRw8BAQdAINFDmM+bgGkT1C4nD5a3BxgcH8Xnx5qTJbPuIBxD57LN MkNoYXJsaWUgTGkgKEZyZWVCU0QgUHJvamVjdCkgPHZpc2h3aW5ARnJlZUJTRC5vcmc+wpkE ExYKAEEWIQRTQA7vBfo8y1zE1rpnj5NgWEFcygUCZFWWqAIbAwUJA+3ogAULCQgHAgIiAgYV CgkICwIEFgIDAQIeBwIXgAAKCRBnj5NgWEFcyllaAP9CGICFEvTUOv5BYh/H8m49VJ87a/wd 0obeQfVBnS464AD9FopTHbjEs0HDV0ZYmJPxzJIznjumsj9gBxX0bBqqTgzOOARkVZaoEgor BgEEAZdVAQUBAQdA6BUWuG5RuT0vmtoDyCUUqiJGdtd78GM5ic3kw2AntSADAQgHwn4EGBYK ACYWIQRTQA7vBfo8y1zE1rpnj5NgWEFcygUCZFWWqAIbDAUJA+3ogAAKCRBnj5NgWEFcyn55 AP9ezKDCUgHqAq6JX976abb9pYdbSjxxNJqnrjgNkfhgIQD/QhR+fgnUHhcGTMBy+pYHZUGH 5DCuITsK1U4+v252uws= Organization: FreeBSD Project In-Reply-To: <87497F2F-8C4F-48C8-8737-979070B41C78@yahoo.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------nxeyVR9FyzCI26O9aJc0GWBE" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------nxeyVR9FyzCI26O9aJc0GWBE Content-Type: multipart/mixed; boundary="------------ErixNfhXqLVirFSlCGD4P0b2"; protected-headers="v1" From: Charlie Li To: Mark Millard , freebsd-arch Cc: FreeBSD Toolchain Message-ID: <5ef8f532-e411-449e-9d0e-798ad9da3c3f@freebsd.org> Subject: Re: FreeBSD libc++ , ports, and import std or import std.compat : what if potential ports start using them over time? References: <87497F2F-8C4F-48C8-8737-979070B41C78.ref@yahoo.com> <87497F2F-8C4F-48C8-8737-979070B41C78@yahoo.com> In-Reply-To: <87497F2F-8C4F-48C8-8737-979070B41C78@yahoo.com> --------------ErixNfhXqLVirFSlCGD4P0b2 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TWFyayBNaWxsYXJkIHdyb3RlOg0KPiBGcmVlQlNEIGhhcyB0aGUgcHJvcGVydHkgdGhhdCB0 aGUgb25seSBpbXBsZW1lbnRhdGlvbiBvZiAobW9kZXJuLA0KPiBjbGFuZyBiYXNlZCkgbGli YysrIGlzIHRoZSBvbmUgcHJvdmlkZWQgYnkgdGhlIHN5c3RlbS4gSGF2aW5nDQo+IHRoZSBw b3J0cyBlbnZpcm9ubWVudCBoYXZlIGl0cyBkZXZlbC9sbHZtKiBjb250ZXh0cyB1c2UgdGhl aXIgb3duDQo+IGxpYmMrKyB0aGF0IG1pZ2h0IG5vdCBtYXRjaCBvciBiZSBjb21wYXRpYmls ZSB3aXRoIHRoZSBzeXN0ZW0NCj4gbGliYysrIGlzIG5vdCBwcm92aWRlZCBmb3IgY3VycmVu dGx5LCBhcyBJIHVuZGVyc3RhbmQuDQo+IA0KPiBCdXQsIGFzIGZhciBhcyBJIGNhbiB0ZWxs LCBpdCBsb29rcyB1bmxpa2VseSB0aGF0IHRoZSBzeXN0ZW0gbGliYysrDQo+IHdvdWxkIGJl IGNvbmZpZ3VyZWQgdG8gYWxsb3cgaW1wb3J0IHN0ZCBvciBpbXBvcnQgc3RkLmNvbXBhdCA6 DQo+IFRoZXJlIGxvb2tzIHRvIGJlIGV4dGVuc2l2ZSBjb21waWxlciBvcHRpb25zIG1hdGNo aW5nIHJlcXVpcmVtZW50cw0KPiBmb3IgaG93IHRoZSBzdXBwbGllZCBzdGQgYW5kIHN0ZC5j b21wYXQgd2VyZSBzZXQgdXAgYmVmb3JlIHRoZXkNCj4gY2FuIGJlIHVzZWQuIEJ1aWxkaW5n IEZyZWVCU0QgaXRzZWxmIG1heSBoYXZlIG5vIGludGVuZGVkIHVzZSBvZg0KPiB0aGUgbGlr ZXMgb2YgaW1wb3J0IHN0ZCBvciBpbXBvcnQgc3RkLmNvbXBhdCAuDQo+IA0KPiBUaGlzIGxl YWRzIG1lIHRvIHdvbmRlciBpZiBGcmVlQlNEIHdpbGwgZW5hYmxlIGFsdGVybmF0ZSBsaWJj KysNCj4gdXNhZ2UgZm9yIHBvcnRzIGF0IHNvbWUgcG9pbnQgaW4gb3JkZXIgdG8gYWxsb3cg cG9ydHMgdG8gdXNlIGltcG9ydA0KPiBzdGQgYW5kL29yIGltcG9ydCBzdGQuY29tcGF0IC4g TWlnaHQgdGhhdCBuZWVkLCBzYXksIGEgbGFuZy9jbGFuZysrKg0KPiBzZXBhcmF0ZSBmcm9t IHRoZSBkZXZlbC9sbHZtKiA/IExpa2VseSBub3QgaW50ZW5kZWQgZm9yIGJ1aWxkaW5nDQo+ IEZyZWVCU0QgaXRzZWxmPw0KPiANCj4gQSBwcm9ibGVtIGhlcmUgaXMgYXZvaWRpbmcgaGUg bmVlZCBmb3IgYW55IHByb2Nlc3MgdG8gaGF2ZSBtdWx0aXBsZQ0KPiBsaWJjKysgaW1wbGVt ZW50YXRpb25zLiBUaGlzIG1pZ2h0IGJlIG1lc3N5IGVub3VnaCB0byBibG9jayB1c2Ugb2YN Cj4gaW1wb3J0IHN0ZCBvciBpbXBvcnQgc3RkLmNvbXBhdCBpbiBwb3J0cyBmYWlybHkgZ2Vu ZXJhbGx5LCBuZWVkaW5nIGENCj4gZnJvbSBzY3JhdGNoIGJ1bGsgLWEgcnVuIHRoYXQgaXMg b3ZlcmFsbCBiYXNlZCBvbiBhIHNwZWNpZmljDQo+IGFsdGVybmF0ZSBsaWJjKysgZm9yIGV4 YW1wbGUuIChNYXkgYmUgb25seSB0aG9zZSBmb2xrcyBidWlsZGluZw0KPiB0aGVyZSBvd24g cGFja2FnZXMvcG9ydHMgZ2V0IHRvIGRvIHN1Y2g/KQ0KPiANCkF0IGxlYXN0IGluIHBvcnRz LCBHQ0MgYW5kIGFueXRoaW5nIGJ1aWx0IHdpdGggaXQgYWxyZWFkeSB1c2VzIGl0cyBvd24g DQpsaWJzdGRjKysgd2hpY2ggaXMgc2VwYXJhdGUgZnJvbSBiYXNlIHN5c3RlbSBsaWJjKysg YmFzZWQgb24gTExWTS4gSSANCmltYWdpbmUgb3RoZXIgQysrIGNvbXBpbGVycyAodGhhdCBo YXZlIGJlZW4gcG9ydGVkLCBvdXRwdXQgZnVuY3Rpb25hbCANCmJpbmFyaWVzLCBidXQgbWF5 IG5vdCBiZSBpbiB0aGUgcG9ydHMgdHJlZSkgaGF2ZSBzaW1pbGFyIGRlYWxzLg0KDQpXaGls ZSB5b3UncmUgdGFsa2luZyBhYm91dCBzdGQgYW5kIHN0ZC5jb21wYXQsIEkgaGF2ZSBhIHJl bGF0ZWQgaXNzdWUgDQp3aGlsc3Qgd29ya2luZyBvbiB0aGUgd3d3L3dlYmtpdDItZ3RrIHVw ZGF0ZS4gVGhleSBoYXZlIGNvZGUgdGhhdCByZWxpZXMgDQpvbiBhIHN0ZDo6cGFpciBpbXBs ZW1lbnRhdGlvbi9BQkkgdGhhdCBkb2VzIG5vdCB3b3JrIHdpdGggb3VyIGJhc2UgDQpzeXN0 ZW0gbGliYysrLiBUaGlzIGlzIGJlY2F1c2Ugb3VyIGJhc2Ugc3lzdGVtIHVzZXMgTExWTSBs aWJjKysgQUJJIA0KdmVyc2lvbsKgMSwgYnV0IHRoZSBuZWVkZWQgaW1wbGVtZW50YXRpb24g aXMgaW4gQUJJIHZlcnNpb27CoDIsIHdoaWNoIHRoZXkgDQpoYXZlIHN0aWxsIChldmVuIGlu IHRydW5rISkgbm90IGRlY2xhcmVkIHN0YWJsZS4gTWVhbndoaWxlIGxpYnN0ZGMrKyANCndv cmtzIGZpbmUuIEdpdmVuIHRoZSBjb21wbGV4aXR5IG9mIFdlYktpdCAoYW5kIGJyb3dzZXIg cmVuZGVyaW5nIA0KZW5naW5lcyBnZW5lcmFsbHkgYW55bW9yZSkgYW5kIGJhbGFuY2luZyBt YWludGVuYW5jZSBjb25zaWRlcmF0aW9ucywgDQp1c2luZyBHQ0MvbGlic3RkYysrIGZvciB0 aGlzIHBvcnQgaXMgbW9zdCBsaWtlbHkgaW5ldml0YWJsZS4NCg0KU28gdG8gYW5zd2VyIHlv dXIgcXVlc3Rpb24sIHVzaW5nIG90aGVyIEMrKyBTdGFuZGFyZCBMaWJyYXJ5IA0KaW1wbGVt ZW50YXRpb25zLCBwYXJ0aWN1bGFybHkgd2l0aCBvdGhlciBjb21waWxlcnMsIGFscmVhZHkg aGFwcGVucyBpbiANCnBvcnRzLCBidXQgbm90IGF0IGEgZ2VuZXJhbC9ibGFua2V0IGxldmVs Lg0KDQotLSANCkNoYXJsaWUgTGkNCi4uLm5vcGUsIHN0aWxsIGRvbid0IGhhdmUgYW4gZXhp dCBsaW5lLg0KDQo= --------------ErixNfhXqLVirFSlCGD4P0b2-- --------------nxeyVR9FyzCI26O9aJc0GWBE Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wnsEABYIACMWIQRTQA7vBfo8y1zE1rpnj5NgWEFcygUCZqetQQUDAAAAAAAKCRBnj5NgWEFcygzC AP4334ujPPSuUIylCIS9y7A750HN4RSWpLbY+IpM6tTt9QEA692P43tA+6LMicX+0CCxXNxLVR3I OYgHTR9wK7NBZws= =UX3p -----END PGP SIGNATURE----- --------------nxeyVR9FyzCI26O9aJc0GWBE-- From nobody Mon Jul 29 15:23:27 2024 X-Original-To: toolchain@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WXhvh2vXRz5RRPK for ; Mon, 29 Jul 2024 15:23:28 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WXhvh1jZFz4177 for ; Mon, 29 Jul 2024 15:23:28 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1722266608; a=rsa-sha256; cv=none; b=uPGW8YQHVKFum44Z8W3TV42/wtjBQWsNUtDbhW1R276Gxii72NtxeLryn7yj+DngMVNKvD S1j7uhjXIUq6dOUpKndfdieoD7VqKH20L4Qm97dRi2RotOj8sAPdrA6GUG4BV24QPCkvJc P7yj1HX3z8Mrgc/JzSwb02Vdn7dLKgh2s3Tmwwv5Zk5L3evqOWiq1EZkH8lAMzzPewbUdd jiZBdNQqV6Kd4JJbsdFIOumj04Ik9u3UXIZs8XquxtNsw8ESlfGWKTkQ2ljZlmnNcoCa0D c3kRd7REAGuduyS9n1S1urJR7ExT8lekrEIYaIzlnU9Z3PMHbNcNrk/Ng9kkog== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1722266608; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zyJEF7DASEK5DpkChE936ferOuj+gOEh06Yxe2acaDI=; b=mksYMKhenKng43npoFOmc8Za8copG3asPRZMmVq9a67Cl9Dp8TS9MPytAHcdFc/DAEQbEY mE+4OBeQ9xtd4+7K7pYVzvZQaaZVjwMmJUdEdyzOiZQ/98kgRhKtdoOuV0rA3AuxcgJpif 224XXhkwB5a/3uX5gijO1eTFC/Ug5d0v/Jb3vHC61yX7vzN65X3Iq4AyfUHa4VgXA/L2pE Qgik6q309gB3lBbIj1hYuTE6UtucPMUgYCDVK3/z3wml0Pt7cdeeLMktpBKEEIMYdAsyh1 vvdFMKJxdKJDXtAJuDx8gws5gMIEFixBjmAKhU5TTa1u21SPsytfxICOxdgClQ== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4WXhvh0k0lzfrX for ; Mon, 29 Jul 2024 15:23:28 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 46TFNSQV090879 for ; Mon, 29 Jul 2024 15:23:28 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 46TFNSaw090875 for toolchain@FreeBSD.org; Mon, 29 Jul 2024 15:23:28 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 279443] LIBCPP assertions are enabled in optimized builds when -DNDEBUG is given to clang Date: Mon, 29 Jul 2024 15:23:27 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 14.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: dim@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D279443 Dimitry Andric changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cperciva@FreeBSD.org --- Comment #16 from Dimitry Andric --- At some point during libc++ 18 development, the old assertions-on/off mecha= nism (using _LIBCPP_ENABLE_ASSERTIONS) was replaced with various "hardening mode= s". (See https://discourse.llvm.org/t/rfc-hardening-in-libc/73925 and various o= ther places.) With upstream's libc++ builds, the hardening mode with which libc++.so itse= lf is built is chosen at configuration time, via the CMake LIBCXX_HARDENING_MO= DE variable. It can be set to "none", "fast", "extensive" and "debug". In the CMakeLists.txt there is the following comment: "Specify the default hardening mode to use. This mode will be used inside= the compiled library and will be the default when compiling user code. Note = that users can override this setting in their own code. This does not affect = the ABI. Supported values are ${LIBCXX_SUPPORTED_HARDENING_MODES}.") In any case, libc++ never used NDEBUG for these internal checks. In -CURRENT, the precompiled shared and static libraries installed in the b= ase system use the mode selected in lib/libc++/__config_site, which is generate= d by a CMake build with hardening mode set to "extensive" (aka 16). I think it may make sense to tune down the level of the shared and static libraries to "fast" for release branches, or maybe even stable branches, as= the "extensive" setting is slightly more expensive. For a particular port that wants to change libc++'s defaults, they should u= se e.g.: -D_LIBCPP_HARDENING_MODE=3D_LIBCPP_HARDENING_MODE_NONE or one of the other non-default settings. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Mon Jul 29 16:01:46 2024 X-Original-To: freebsd-toolchain@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WXjm93qgCz5RVlJ for ; Mon, 29 Jul 2024 16:02:01 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-19.consmr.mail.gq1.yahoo.com (sonic314-19.consmr.mail.gq1.yahoo.com [98.137.69.82]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WXjm91Rrrz47ZH for ; Mon, 29 Jul 2024 16:02:00 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1722268918; bh=Z8khkshwyJW5fotAaYvsc441wggqRLqmnTo+YKuBPp8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ZsJH6B4Tr1CzqcgGgxW5kSVr4XDWIALUsxsSfcUH+B5ZIbkLXl5jSoK7dUlRreulZEa7Ry/VmaKSUooSA1gcUhJ88zabFkQosJZksJZmBUHTrR+/OR/M7RYMVLisRdyzQ0YzNJYxKhnUqSn4Vxem7S50AfLDbaXbkP0N2i9WcTFP/tbPHkD1EqErfaUm5sEprXLhnCov7/s069RKInZqeGOMaz8Mle6lXZ3I+DCbe1yioZ1EDslKntLoSKdGah5MsgD4fGseECh0Ki93c6bHVG+UjJ/nyekOF2iiCC+XC+nD3cmPs4sjYZWghYd1Gzwfz1Tb6O22gApXWiuItTijFA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1722268918; bh=9gbngpArbDmO3LappOo9MYEZvYT1LTUjNnRDQ2msmay=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Jj9X7TI47hkQGiLbAjCAVJqa7orBEROouLcYH2J+Tq9E2i5t7FYqrFkjrKO8I5ZKO/nPqLCatqsvhI7DnlzmS3qrY4mzVr/EIQ24KjA2LffwwOWzvyy3M1JkQmLY6s92EiZQC+G9LI+uVqVosPxfVFE4yaYJ9ujOTm3UUlQIwYfIHzFh7NcDTJqCVNuEY0ICHcNt/+gTKe9hPM3OggKmWRy14fccCymMa7GBW/b8yx+Npz7YnLaGh6ae7Q8t2ZxsreLoCCZIjl+dzNphWx+d3ZSR7E+n6wVdVVV8gDwlONAtx/VLK9dq4BpeNVz2YJBQ/6UyMpYHK3OSOu7P8Uf1mQ== X-YMail-OSG: LOS1klEVM1kkJAmbPOsZdpV9Ffstn4Qp.AphXYJg2jl8PtVZstm7mYFfymRs0uW 9kSTLB_3239NctggzYW1mQfeRGn1m6aCdDWa3joKB.nbt9yC_z.oKhRaiW1YOkOuQxML0WNf4Cxi BdAkmMWwtKz3TsclIaycM5SYEKVUmPkmMP68XZIjKCygrUYcSM_LQTTJNpPRDfZ_L5k6tylKexil JF7lcMWud5n79BoOjyXU3_LTyvtBtJ9YBiCOTJQa8WmJG2Nf63dBy2pnmdpkKU8tEp0LpBq.ro0a VTA1SI3NhTlEvOjwj2rhRFftujZb_uzHapOP6iHL2KvlGJLFgulJOX4iQtBRKAjwS4K2Tin.NVKH FrbBaVkTVfVObJII7Pom4LTfIE3rvfioj15w5ipzM5PbLCvpOS_.gfQBf..gswb70ifflSxj2UiJ YaJR39wKehN8xl86f0oH6zLwLDmNj5bB6.biP9pCEnp2ykdvv2heYR4fc6mgzXSYSfNL.tGo0E_H txSPuw6vqLT4bSsL0dl9pJkyM.a819xJ00oO.1EXvafUnb.NCyX7z.nYPalQDTv1_2z3.cEExkbx 7QefuYoVk5ymfVJAs_X3jeb.qD3S2a1Ls.r28pShImjiOm0MQ06OIWh6.mAituVg0.F60iQBuHMT AKibHQvJahG8KCNa6cJVoaZaJ2iwVNlb8ETtieLrGqON.BmQ4X3LWMenLq68ZQn0dm_XfVxOipkY yromMlTv7bl5riy0Ds5uAjzPQISPfmScYUY7XB4eIxAWHjIm97h9rYVv4MtTGzIZ27aq2MY0KSc8 GQVddOTFYBQ79Fa2KXdZnDkQ8tQ9ReRDgEuy5dc_xnFZQcZxskq1PSROlxcpUjFu7k.LtovFaq7S QHmb6fukzgkKwfMYfXqCREjPVs6K4UpENpS_lLcArFUJTqpXpW4DUrM1QFVNNQXRjRzWGxWNHR87 KrWVo3kemQGe5sk7Mv7dIGD5aA4fmhncr516ARoqB6S7Lc0Nu6J7mEtf.QEYjN5J6IJypw44VqG0 fyQxAkzMSX1zWEgJ2woY9EhkLynXTKI9MKEoVo68V1eepw_CigRXkLygelL8pRkGH8odd71Ol0k6 s2HN0PaFcxApEgAN2DKVjR.H3Pt0N6p6v47iXOaDh8EJC18E731B1s9JAkHJxTsRb6Bp2gbJJNl2 rcRzu.NM0TcRRVsIfJVRVYZz6R70dqzuqDLg6sbjW8AwJBwcV0B_sLtElUOX5goPIPNdi0Du9_Ao uPaiiXKpFIu0FXIXuc0AdDvKrRSlovIV3kZAMSDmQoqhhw3lC_KnM9Qz9Rt.WCvXz9mGKYlOizmc 2bkR1nki20CHveA6ovMei_j25kYyLfL2cGH3TIAeIBnJ3Cw1nuIlu3_r3T9HxpScpaIR2_NlMpYb 4b4yREGZFFaz3XqqpAQQaocKy9EOMtWSgdReU4r6CEUThr1_FxaY6_w0KOB3cmt1HGGNqgEgWqlB QppBCd8hO.hE2BxPHGQmG6ZzsKfU_ic5eYHr.Stx2iKOiqyP0D6AFeWdSGe8hAhzzEjS2A3576CR 01Jl3w8OgZ4egrU1Gzdlblnr0CagHNTAXlRR45mu.MasJ_cfG.jERYHcIyeLVf5dL6iJ8nndyryA YWlhSDe77WmcTxRoqJ2ln.hGR5H2m3b80G1x1DNNIvQZn3vlzoVQSsQ666bbt2MfYOMyNkZqBacx emLKhqfB97wkGjKqlAHY3EKBFYu2pXFt3JojXe9olfCoWqX526lqfNJTiYbIL7D7QvSGSjEbR7f0 bQCtALYMi8frTjRK5Nr2jRuSOutVVpTFzfAbvdV_fSS4Eo_kFvC.6Lkp3_hryzZYRCWwrTKoMsQC UaCCzCFMK1UBf7BDiy7eHKb.M28cYFfKRSEI2ssnVSenbLzOdDQ1pPj2NtWfBSFeV0Jxcq.6rIoI _dtAFI9gzyXu0C.HbclFllrXnK7Gi4w8nCAMLY8jxIGA1fmSHjFRNcVxfSklCA_SZ7Xe_feBACu3 HReP5lysgeV5esR_ra1lT9w24RbXkHVfaCf.kLMK4EMHZJsq597Nan..3pUPb9iOIFMukOlh3yWj ZFbDgFT.b9oAgAQncEjLw28ua8XSvfrLPXWKTvHGYWZv1zjn9KT7.V_zT5GVOdWjNK4jXqhInkiA bMgPCX_wJf3Ov2XTEBhhYzNmhvJ.mA88OBMrLwAz7k54nmwB55caMFI9vKqy9EKAJCxfvCjvuduD wu7PbWbPpW4WdQZrbKZZuob4PzKA9rQZ4tV0LLUScjBKzWavlmOfGeGMwFXA7V5tc4wEnjaVVdts j X-Sonic-MF: X-Sonic-ID: bc78f1c1-a040-44a7-9614-ac157531a82f Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Mon, 29 Jul 2024 16:01:58 +0000 Received: by hermes--production-gq1-799bb7c8cf-wncxc (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID a1d03c9e62fd9bab7ad9550b983f4cff; Mon, 29 Jul 2024 16:01:57 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Re: FreeBSD libc++ , ports, and import std or import std.compat : what if potential ports start using them over time? From: Mark Millard In-Reply-To: <5ef8f532-e411-449e-9d0e-798ad9da3c3f@freebsd.org> Date: Mon, 29 Jul 2024 09:01:46 -0700 Cc: freebsd-arch , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <22A8133D-B6E6-4818-932A-5D6B03882AC4@yahoo.com> References: <87497F2F-8C4F-48C8-8737-979070B41C78.ref@yahoo.com> <87497F2F-8C4F-48C8-8737-979070B41C78@yahoo.com> <5ef8f532-e411-449e-9d0e-798ad9da3c3f@freebsd.org> To: Charlie Li X-Mailer: Apple Mail (2.3774.600.62) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Queue-Id: 4WXjm91Rrrz47ZH On Jul 29, 2024, at 07:54, Charlie Li wrote: > Mark Millard wrote: >> FreeBSD has the property that the only implementation of (modern, >> clang based) libc++ is the one provided by the system. Having >> the ports environment have its devel/llvm* contexts use their own >> libc++ that might not match or be compatibile with the system >> libc++ is not provided for currently, as I understand. >> But, as far as I can tell, it looks unlikely that the system libc++ >> would be configured to allow import std or import std.compat : >> There looks to be extensive compiler options matching requirements >> for how the supplied std and std.compat were set up before they >> can be used. Building FreeBSD itself may have no intended use of >> the likes of import std or import std.compat . >> This leads me to wonder if FreeBSD will enable alternate libc++ >> usage for ports at some point in order to allow ports to use import >> std and/or import std.compat . Might that need, say, a lang/clang++* >> separate from the devel/llvm* ? Likely not intended for building >> FreeBSD itself? >> A problem here is avoiding he need for any process to have multiple >> libc++ implementations. This might be messy enough to block use of >> import std or import std.compat in ports fairly generally, needing a >> from scratch bulk -a run that is overall based on a specific >> alternate libc++ for example. (May be only those folks building >> there own packages/ports get to do such?) > At least in ports, GCC and anything built with it already uses its own = libstdc++ which is separate from base system libc++ based on LLVM. = https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.202= 0 does not yet list a version for its "Standard Library Modules std and std.compat" entry in its "Table 1.10. C++ 2023 Library Features". So it will be a while before both clang++ and g++ have support. Such is part of the reason my note is a early warning. These days the more modern ports lang/gcc* allow use of -stdlib=3Dlibc++ as well, allowing the use of the system libc++ library when it is compatibile. But that gets back into what my notes report. But, as far as I know, system clang and the various devel/llvm* are not configured to handle -stdlib=3Dlibstdc++ . (Such would have to get the library from a port or such.) libstdc++ is GPL3 these days as I understand, which may be a constraint for some contexts. > I imagine other C++ compilers (that have been ported, output = functional binaries, but may not be in the ports tree) have similar = deals. >=20 > While you're talking about std and std.compat, I have a related issue = whilst working on the www/webkit2-gtk update. They have code that relies = on a std::pair implementation/ABI that does not work with our base = system libc++. This is because our base system uses LLVM libc++ ABI = version 1, but the needed implementation is in ABI version 2, which they = have still (even in trunk!) not declared stable. FreeBSD updating its C++ ABI would be a rather major change, or so I would expect. Likely avoided as long as possible? I wonder what property of std::pair's implementation is at issue for the ABI version distinction(s). > Meanwhile libstdc++ works fine. Given the complexity of WebKit (and = browser rendering engines generally anymore) and balancing maintenance = considerations, using GCC/libstdc++ for this port is most likely = inevitable. >=20 > So to answer your question, using other C++ Standard Library = implementations, particularly with other compilers, already happens in = ports, but not at a general/blanket level. At some point lang/gcc* might become an alternative for code set up to import std or std.compat . But until that happens, fewer projects are likely to try to use such imports. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Jul 29 16:18:52 2024 X-Original-To: freebsd-toolchain@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WXk7h3SKPz5RXMx; Mon, 29 Jul 2024 16:18:56 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WXk7h2tsbz4B84; Mon, 29 Jul 2024 16:18:56 +0000 (UTC) (envelope-from dim@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1722269936; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=7dvfJHG8sy4fESMTbEL2Go2gyZykAe7nl+IeVy1er0s=; b=CO1N+/5lgjgcqQr8KoHavUCV2jVjPsWQlRtN7Gg6WJrCzJba6+xVnDethTw/wOnSXnhw4P 5E1+Lci8Wqnds07r34gs1YghNvnX1KXEShCRjJZKReDiXpBdP1gQTh0GZhlCsPeoEfA5ZC o4mLwxow9zp+WQTWsw+2c6bqlis1mF/BC8tNXlywy3BKs0IJKJvYgU8M00fNUkdhL3LHbK 087tRDEDyQD6NLh6n4Jh0furaR2mlUIAgWOTI9VsOFkQL6Kki6bZZJgxlMH8jRLfMnQk38 nk29qaZjtv0PfYyCOqQimoU8H4tTGP25LTpkhzJl9Me3GKC/dqGEcsS8OfT0Gg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1722269936; a=rsa-sha256; cv=none; b=hDs7UeSsXCkjiUu3xLG7DVeo2IVh8kKJ7dt1GowbgIypT8++nEfAi+9cjPAQSOdf3i+sCO y1+7fTiHb/w8lBCPbpXdY/O72bbNHjJI4Hac16Ese3rJZxJqeqBuB0j54Dq7tOaqlfFl2d /dDiHXFJoLiHAa//Zgi/Yjnow5jO3XYokIDjhnGa66Ip82T2ccfPo+b8pNAmmUXWF20aVs bSrLTTsv6zwlM/o+Pp6enjS6Q6cEkAKq4L9wXlhACkcu98m4RHDW4blgXOTryQdkKe64zj jchKva2mv8LG3MrYQ8LSeVtVRrHJEL9PT9DKi//VPovA27VV2seqhlIgFy4yaw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1722269936; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=7dvfJHG8sy4fESMTbEL2Go2gyZykAe7nl+IeVy1er0s=; b=x2L0vNhjVe/nL5LXLHra+MBoUkhLnBYfrfbeGEdjiIzocOyWY51MVlN7YrO+1Jba93qJsp SrNzLwzJzkkkUZkW40J220dwyKDTjFGHsNztcDBt+tA4yWB8BoFw5v9KyCiQZAiklwl4rb Vrp8E/BTgSLxPk2hwwkggt9GBBhe5XbhcHQ0kkTNE/GiyDZatAGOWk+gEj5WbbrCp91vll 3JQOAig6/TZ9MXcumBzuEGXvuw+UnhYTKVGfGxlcsBNoxcRg7O7a37HpoWVevpTiZsIWtQ aklGHzDwxQCyuSPQACLzjQwIS3hQO/uVMYcCOAQg3Ee9dy2tE+Tq1mzBUqtsXw== Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "tensor.andric.com", Issuer "R11" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id 4WXk7h1mKCz1PWP; Mon, 29 Jul 2024 16:18:56 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtpclient.apple (longrow.home.andric.com [192.168.0.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 66737565E0; Mon, 29 Jul 2024 18:18:52 +0200 (CEST) Content-Type: text/plain; charset=us-ascii List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6.1.1\)) Subject: Re: FreeBSD libc++ , ports, and import std or import std.compat : what if potential ports start using them over time? From: Dimitry Andric In-Reply-To: <22A8133D-B6E6-4818-932A-5D6B03882AC4@yahoo.com> Date: Mon, 29 Jul 2024 18:18:52 +0200 Cc: Charlie Li , freebsd-arch , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <03578B4A-BA6A-4F9D-BCE0-9C01A84623C5@FreeBSD.org> References: <87497F2F-8C4F-48C8-8737-979070B41C78.ref@yahoo.com> <87497F2F-8C4F-48C8-8737-979070B41C78@yahoo.com> <5ef8f532-e411-449e-9d0e-798ad9da3c3f@freebsd.org> <22A8133D-B6E6-4818-932A-5D6B03882AC4@yahoo.com> To: Mark Millard X-Mailer: Apple Mail (2.3731.700.6.1.1) On 29 Jul 2024, at 18:01, Mark Millard wrote: >=20 > On Jul 29, 2024, at 07:54, Charlie Li wrote: >> ... >> While you're talking about std and std.compat, I have a related issue = whilst working on the www/webkit2-gtk update. They have code that relies = on a std::pair implementation/ABI that does not work with our base = system libc++. This is because our base system uses LLVM libc++ ABI = version 1, but the needed implementation is in ABI version 2, which they = have still (even in trunk!) not declared stable. >=20 > FreeBSD updating its C++ ABI would be a rather major change, > or so I would expect. Likely avoided as long as possible? >=20 > I wonder what property of std::pair's implementation is at > issue for the ABI version distinction(s). It's a bit of a historical wart that is hard to get rid of. In FreeBSD = we were "too early" and changed our standard C++ library to libc++ = before this std::pair trivial copy constructor issue was hashed out in = the standards committees. After it was settled in those committees, = libc++ changed its implementation to match, but this actually breaks the = ABI! For anybody who switched to libc++ after that time, there was no = problem using the new ABI, but in FreeBSD we have been stuck with the = older interpretation ever since. Changing the ABI involves bumping libc++.so to .2, and putting = libc++.so.1 into a 'compat' package for the sake of old binaries. I had = originally wanted to do this for FreeBSD 14 but never got to it, and for = some reason upstream is also stalled for years now in bumping their own = official ABI version to 2. It would be preferable if upstream libc++ bumps its 'stable' ABI to 2 = and starts working on 3 as the then-experimental one, then all = downstream consumers can upgrade, leaving all compat crutches behind. -Dimitry From nobody Tue Jul 30 05:14:55 2024 X-Original-To: freebsd-toolchain@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WY3MN05QBz5RDW6 for ; Tue, 30 Jul 2024 05:15:12 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-22.consmr.mail.gq1.yahoo.com (sonic309-22.consmr.mail.gq1.yahoo.com [98.137.65.148]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WY3MM4DFVz4nSN for ; Tue, 30 Jul 2024 05:15:11 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1722316509; bh=y4H24XACsjg1xCVMniuXl3MHUC8+oH98FzI8lOTM6OA=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From:Subject:Reply-To; b=LvydplI2sCM+rFMeON/Um28JpSplqEP8QYNn1VxOLDGETm/MjdI+HW2uedaLv7GrUVsVYTk93kDrHH0q3EpTBlqsxLqRIAj/Mon+pj9ECgZ97RYFaZ4IGxMWHdEIQ0y9PXxT1+EzVA+sPs0RtZoiRhnZEmlUbVic5X31097Z9yb7PGHRlO59gaVTw+MAHWP9yKoXn7TrjicJaK8U0jgrmUSOxfgbvoH0X6etR/Yb0n0KXaqHOjBtTG+1hWFWZnvqKrKoxuo3kcxKlZaTvA0Klzamb4ewy8Bq8p4GM27NTbkoZe73ZK47mAn6+cpvkib4TCd5XBX8lHTrwTAfO7T23w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1722316509; bh=B0eCtimtqxzlGOZ69tNMCU6YFSSDaueUeZcbR0Xorda=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=IviNOJ4fR0pyS/lCIZF/smrfSLipkLpbGRSRnxH9hRNl/CuKSNr85uZwA+nkrBpiQoXgtjMLBQcFd/ufgUMoYNpYJmrW83Qe5+kByOsBM0OWwUjWklvVyvaHCW6EKJpAJb5l9Df15JpF3MWXu0SH7e4t6rdLCLOPqHrVBhXaaiFjiB1TXnX9i5Y44A4KZGZ+Q78L3TsmcmvhaaYkGT+Pr3pB5CVBEGUz98WdzBYF+kRulTpauS6Y8FUAvGnP8tGuCClkDLy9HVAJt3IxaDqNj6ozayw1j9NN2uIkTdNJjA9uLTXF39vEjoyfNNbTILrsDPL0svSaxjUSCZNtpXDgAA== X-YMail-OSG: HoJ5Zk0VM1mlwcAjFeWd.FFDKIqxGPg_dNuNsnyTU53oVaNaRrJGJpxaOm193Ua Z4sDYDEZHsTW8AVbEsckXWy1Bed.46K9FTC790tE_zfQsWC2vbm8CwB4mLwYJrMwI01sNE3d5DeY qj7LhAm0czZEaP5QAcjAKWQ.u5lM7pMB_AwqZmhN9nQEzzpn1CWKMI7oOZNyAM1OwClG8x8JY1wu XhnjitPJO5_gLbclUtJ5ThQNpqmUVbYtj_UPDPfxiWgN.Le8QrGiB1wWvSj_InOP0Tlsoq0oniOs ujHXP_Vip8B8UettHq5qr5.dsAE5f5jOVvmhUZs0LoHUpiaN73uNfSdhnMN.acr.i201znZcBGfG iVP2AslAg1vglhrnTbzLgAWK.WxaJmSZhpHeqrgfvm41ynzYJ7GbSxL.FNDJA1FrLXSySKy0L4I3 WcFNz3WWq291YnOrJsvzWsMTmEGIutO9NhRrDADiB7a8RHIao7qz71p61D.y0FzS8.ZCV2TVciF. RYZ8btWvZFF3fo1C.fg7_F8a5GKBgDfDMoC2xNg.1EtRPz5Ce.AhYYpCt5t.UUNBFQq3A0c2OeO8 a5yLMyKIpW6_K6qLoYnlFVP1qMzU9xqMVGsNl7UOb9g3UDc0G02UrIPr7c3sVkquvONiVdD7sEii au_fSbeEhihIlNORGO58y8XNHmSo86Yjh7fk3h6N__yfKILk7RbaQ_NblIUBsFUPA7G.Cc3dTsVy hc6XU5DMSSjrEOrbZzBfSpcddJT1ghgIGeGKtXdq66mNKrUfubK0toWrpWzp_J5W5_a.MSycXshC R07q4pD8k_WLcmPDyrvMCNWGReQQDeBmZLACAXhgGxYg0yr3KWpfstyi0EpW2S5MiZE.NEhX4b5r pts0Ym3WdQBTTUSq4b3UaLFp.BBCQaadVZHVWyOFn9LeaI74qRYheUdzynZe2Jpqec8XuAVowWvv IcofUgaiVIblz_yDCy_TKw4WYymX0lJ5fRmA8Omp33duj18kM1TW8O90ZvgPIQw6iiDjIdVsb.nH Myb1bz7HBTlIHbfRibDPzpHijNZH55hAqisGTZuG6nUx.OxUFWjqXYedjPOnbW7xGP_dIwR0O7Le BEQx5pML63LatfRtW_7A061X6oyerIfdjG16KiYfJzS3rk1fA0qVHt3MKjQDhaqWXIIp7kNei3p7 .z11gBhF867rxRAjhZaM6GTgFlAMSue9S4gB8QpaPec2qTMeK37Vkd.8oX9tgJLuiy_jsKdAHRnA XP.ySdxsLVMFnzNX_CYqCiIFpfg0oAmWzYQktaoRXhXPgqyq.s0PNafXcl_OMvcvK9pD3wfchV_S sOESf6qVfgV2HvMqlZIvHexRvnOrJZxI9wsEtIW8IBuhC43RQPK7SmX9M56XiWP0d5HjnbTdMiNc HXggjLU.r8kwtaRImUwdLGB01yea09pKnVrge19tH7fiD_WPj1D0IvIWQtZWOqsM6w.GurdptCAS _IOaGYw2yqwc14iV926zu86FMXoKpZy78ehNWhzaNoJHgBumhr_MIJIXu3266.iQ6DI9NZ2sIYxJ p4uY4mZnr7YlSXkP5Qc6hgL3asqoOqiGnr4hraeTJ16IRLUr3SS_AryHL0Jzosyf8srfNRpqJNsR LuilkSEzp6RgPzrxX.XkPFzDGmt375SmmGP0z.YKJLknmlGD.UYZiffWazu7HjeDy50WoKmyK8HM gZ03HjUAKpFu56hMEN.uaDOY5DQbtmcWCwXWBcSjfYJ0yoNbPF_rch41E7F17jjVPTMfeE0r6xZP v4MQXISPMDIYfRvLEiv73Kaz4A_Qpws3hUtoEz1j7sI.FelFQlgs62Lb8ieSCRa.glq74q9oHJCl ezFjtCpYWQGO.MSjfDmXEOW0IR7AKsRyLLUqAANLMsB8KwSu8uRxLMYNJFv_9d27r1gNRAOnlwiq NaWv1pRd5YO3vu9QtiDC9pTKFaHCTExZYjSQ9boJ26UKyVJo24ge03XotH80oDC6RnveC7iAz7UN V6YBhqKPugNIZfmcoZ5PSIVqNtHykZ0VW5.iTXvH467_gl77wl7JYD15FBqY00fSdt3LErLfIaHR d1o3NjrHtZnhksfIuH0LWavJq.fMG7djCN9ZBUpR2yyqa0zVpuhGQCCVn1kUKVYzg2YYsKcp9e2O gwZS2cq.tRwNZeIQnr9MwOdjm7jtGhdvjt7q18YF2Erhu2Xz89E.v9s.gb4mpsk7vx1HZj95dakV Lhy2EFQw.9zKbVc_l2V3hJ6othe6q3M1e70Wo1lZoP6Kmt8hupYs9yHKgQvpMXRYJZxYEHRVh7wy ijP.2a6QEOqf9RHFoxA-- X-Sonic-MF: X-Sonic-ID: e61a8420-bf75-4819-bd7b-60e6aaabbe88 Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Tue, 30 Jul 2024 05:15:09 +0000 Received: by hermes--production-gq1-799bb7c8cf-cvhk6 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID d2cae25f9c3d7c1c003d12974b7a5cec; Tue, 30 Jul 2024 05:15:06 +0000 (UTC) From: Mark Millard Message-Id: <98D4961E-2BEF-465E-8ACE-99587A089951@yahoo.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_CED38DD1-2D05-4B3D-9BE6-C999AC294AE5" List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Re: FreeBSD libc++ , ports, and import std or import std.compat : what if potential ports start using them over time? Date: Mon, 29 Jul 2024 22:14:55 -0700 In-Reply-To: <03578B4A-BA6A-4F9D-BCE0-9C01A84623C5@FreeBSD.org> Cc: Charlie Li , freebsd-arch , FreeBSD Toolchain To: Dimitry Andric References: <87497F2F-8C4F-48C8-8737-979070B41C78.ref@yahoo.com> <87497F2F-8C4F-48C8-8737-979070B41C78@yahoo.com> <5ef8f532-e411-449e-9d0e-798ad9da3c3f@freebsd.org> <22A8133D-B6E6-4818-932A-5D6B03882AC4@yahoo.com> <03578B4A-BA6A-4F9D-BCE0-9C01A84623C5@FreeBSD.org> X-Mailer: Apple Mail (2.3774.600.62) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Queue-Id: 4WY3MM4DFVz4nSN --Apple-Mail=_CED38DD1-2D05-4B3D-9BE6-C999AC294AE5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 29, 2024, at 09:18, Dimitry Andric wrote: > On 29 Jul 2024, at 18:01, Mark Millard wrote: >>=20 >> On Jul 29, 2024, at 07:54, Charlie Li wrote: >>> ... >=20 >>> While you're talking about std and std.compat, I have a related = issue whilst working on the www/webkit2-gtk update. They have code that = relies on a std::pair implementation/ABI that does not work with our = base system libc++. This is because our base system uses LLVM libc++ ABI = version 1, but the needed implementation is in ABI version 2, which they = have still (even in trunk!) not declared stable. >>=20 >> FreeBSD updating its C++ ABI would be a rather major change, >> or so I would expect. Likely avoided as long as possible? >>=20 >> I wonder what property of std::pair's implementation is at >> issue for the ABI version distinction(s). >=20 > It's a bit of a historical wart that is hard to get rid of. In FreeBSD = we were "too early" and changed our standard C++ library to libc++ = before this std::pair trivial copy constructor issue was hashed out in = the standards committees. Looking, I eventually found ( __config ): # elif _LIBCPP_ABI_VERSION =3D=3D 1 . . . # if defined(__FreeBSD__) # define _LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR # endif and ( __utility/pair.h ): template struct _LIBCPP_TEMPLATE_VIS pair #if defined(_LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR) : private __non_trivially_copyable_base<_T1, _T2> #endif { . . . So this is not a 1 vs. 2 issue: it is a FreeBSD-specific odd definition = of 1 that does not apply to other contexts with _LIBCPP_ABI_VERSION =3D=3D 1 . I'd = not noticed that in the prior references that I'd run into. (It fits with = your wording below, sort of "early 1 vs. late 1" to invent terminology.) > After it was settled in those committees, libc++ changed its = implementation to match, but this actually breaks the ABI! Sort of "FreeBSD early libc++ ABI 1" vs. "normal late libc++ ABI 1" = ABIs. > For anybody who switched to libc++ after that time, there was no = problem using the new ABI, but in FreeBSD we have been stuck with the = older interpretation ever since. >=20 > Changing the ABI involves bumping libc++.so to .2, and putting = libc++.so.1 into a 'compat' package for the sake of old binaries. I had = originally wanted to do this for FreeBSD 14 but never got to it, and for = some reason upstream is also stalled for years now in bumping their own = official ABI version to 2. If FreeBSD wants an officially stable libc++ without the forced = __non_trivially_copyable_base<_T1, _T2> then it could: ) have libc++.so use .2 for libc++ _LIBCPP_ABI_VERSION =3D=3D 1 without = _LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR defined ) have the _LIBCPP_ABI_VERSION =3D=3D 1 with = _LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR defined case for = libc++.so.1 put into that 'compat' package for the sake of old binaries There is no reason to need to deal with _LIBCPP_ABI_VERSION =3D=3D 2 at = all for the issue at hand. (Yes, this would mean going forward that for N>=3D 1, libc++.so.(N+1) = would be for _LIBCPP_ABI_VERSION =3D=3D N without the FreeBSD oddity.) > It would be preferable if upstream libc++ bumps its 'stable' ABI to 2 = and starts working on 3 as the then-experimental one, then all = downstream consumers can upgrade, leaving all compat crutches behind. >=20 How important is having a numerical match for = libc++.so.(_LIBCPP_ABI_VERSION) instead of the +/- 1 shifting between = the .so and the _LIBCPP_ABI_VERSION ? =3D=3D=3D Mark Millard marklmi at yahoo.com --Apple-Mail=_CED38DD1-2D05-4B3D-9BE6-C999AC294AE5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Jul 29, = 2024, at 09:18, Dimitry Andric <dim@FreeBSD.org> = wrote:

On 29 Jul 2024, at 18:01, Mark Millard = <marklmi@yahoo.com> wrote:

On Jul = 29, 2024, at 07:54, Charlie Li <vishwin@freebsd.org> = wrote:
...

While you're talking about std = and std.compat, I have a related issue whilst working on the = www/webkit2-gtk update. They have code that relies on a std::pair = implementation/ABI that does not work with our base system libc++. This = is because our base system uses LLVM libc++ ABI version 1, but the = needed implementation is in ABI version 2, which they have still (even = in trunk!) not declared stable.

FreeBSD updating its = C++ ABI would be a rather major change,
or so I would expect. Likely = avoided as long as possible?

I wonder what property of = std::pair's implementation is at
issue for the ABI version = distinction(s).

It's a bit of a historical wart that = is hard to get rid of. In FreeBSD we were "too early" and changed our = standard C++ library to libc++ before this std::pair trivial copy = constructor issue was hashed out in the standards = committees.

Looking, I eventually found = ( __config ):

#  elif = _LIBCPP_ABI_VERSION =3D=3D 1

. . .

#    if = defined(__FreeBSD__)

#    =   define = _LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR

#    = endif


and ( __utility/pair.h ):

template <class = _T1, class _T2>

struct = _LIBCPP_TEMPLATE_VIS pair

#if = defined(_LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR)

    : = private __non_trivially_copyable_base<_T1, _T2>

#endif

{

. . = .

So this is not a 1 = vs. 2 issue:  it is a FreeBSD-specific odd definition of 1 = that
does not apply to other contexts = with _LIBCPP_ABI_VERSION =3D=3D 1 . I'd = not
noticed that in the prior references that I'd run into. = (It fits with your wording
below, sort of "early 1 vs. late 1" = to invent terminology.)

After it was = settled in those committees, libc++ changed its implementation to match, = but this actually breaks the ABI!

Sort = of "FreeBSD early libc++ ABI 1" vs. "normal late libc++ ABI 1" = ABIs.

For anybody who switched to = libc++ after that time, there was no problem using the new ABI, but in = FreeBSD we have been stuck with the older interpretation ever = since.

Changing the ABI involves bumping libc++.so to .2, and = putting libc++.so.1 into a 'compat' package for the sake of old = binaries. I had originally wanted to do this for FreeBSD 14 but never = got to it, and for some reason upstream is also stalled for years now in = bumping their own official ABI version to = 2.

If FreeBSD wants an officially = stable libc++ without the forced __non_trivially_copyable_base<_T1, _T2> then it = could:

) have  libc++.so use .2 for = libc++ _LIBCPP_ABI_VERSION =3D=3D = 1 without _LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR d= efined

) have the  _LIBCPP_ABI_VERSION =3D=3D 1 with _LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR d= efined case for libc++.so.1 put into that 'compat' package for the sake = of old binaries

There is no reason to need to = deal with _LIBCPP_ABI_VERSION =3D=3D 2 at all for the issue at = hand.

(Yes, this would mean going forward that = for N>=3D 1, libc++.so.(N+1) would be for _LIBCPP_ABI_VERSION =3D=3D N without = the FreeBSD oddity.)

It = would be preferable if upstream libc++ bumps its 'stable' ABI to 2 and = starts working on 3 as the then-experimental one, then all downstream = consumers can upgrade, leaving all compat crutches = behind.


How important is having a = numerical match for libc++.so.(_LIBCPP_ABI_VERSION)  instead of the +/- 1 shifting = between the .so and the _LIBCPP_ABI_VERSION ?


=3D=3D=3D
Mark = Millard
marklmi at = yahoo.com

= --Apple-Mail=_CED38DD1-2D05-4B3D-9BE6-C999AC294AE5-- From nobody Sun Aug 4 06:07:59 2024 X-Original-To: freebsd-toolchain@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Wc8JJ21Hyz5SCX6 for ; Sun, 04 Aug 2024 06:08:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-21.consmr.mail.gq1.yahoo.com (sonic313-21.consmr.mail.gq1.yahoo.com [98.137.65.84]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Wc8JH2QGVz54Zg for ; Sun, 4 Aug 2024 06:08:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=gfEnkWVd; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1722751692; bh=il8f7tMy4JNZLwsHZ6t2Kq3jKwpkLQZHtXV9bAebsZE=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=gfEnkWVdOPi3RFNBREqphBUPqvQ68nJF+BvCoGkc+Eo9RbtZHjQfYVq31YzW8es15quxDK7NmTJQJacDDI5YEGD2biK3DNwFb/rXTfRZmMtGpGK9OKpzMyy6x+aKTUv+Yaum/5k2s2iMajNvD3PP9DMo2L9r7G4Pu3VK0iD/dqOGjcd/lFHc9LuaQ20wundFs4D7SPVWGf/gUYUFe+q/W223qsTSfhZGqd5ZJGycSho6gsZhkQkSVO08Tdvd/wIgvFUA7KO+AWsW1Zw48zJuzl8mwLRtESQwDWAHhMpELrrZBE9zbutIYzx3r5Cy+0HJymld++nZRpzAh2gNxy6eRA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1722751692; bh=jI6I9S4LJYy2r4cLw0w9R0MlEH4V6BmrTZDrIcyAIfg=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=KTOU4k7m2APLeO/ItK/eBHDS7xm22s3ilcgq4d+s17p71ZRJ6LcjnKKNeFejs7iza/exkXIS926IFkkE83VZTK0qFKkWdPUQbD032S1EcjRBXUckXYVUJqbNSo79mfQdZz4n+Dc4DWdIkjLq1S6Pwi2umwSxy9ehby0tpSdJ6k91Z0Yg2pjf2EEB5zSxoVv7OBhCgBRKrxdmlKnWyagIri/FQmDIIc1cfKYYXnQXogeU3GXy10t1UQBOBjKjX6A8wyNPpe4/rUTBRBl7PogZDV1+sT2MueUmIPY5w/ji/DW7Ar5Egf0oj88ZIIBMMFfWwnp1igSjaWQm3EkRbfCqyg== X-YMail-OSG: FJQmaBAVM1koVFTvp7id_mtTyhDydESbz8peTPcmNxBs.OHYK7u1V4lf2WDq1fT 3zZLrOvJSB4ddzGLhakIz36DTVSVnhtmCEwFaeGmPc5kL3swd7L3vHlOw6kx99PoXM9dxOedXfhP kRGeFUGD3zKswRkiMnYnf3bx7GkwS1nYHrQ.1UdrRO7buu2aPoM_m82T0bIyfhzHmmtYLjMiQ0cD dHdiO2CXOCNZQwgQPxqe7dsNArzRlvWk_Qqbrss0mdIHyowZKmN5kK8R51xw2dWwnN7573TMjk3P ivFGY0cY9OX08CObkECxP4pziiGzIBFXyqMU99vtR6nuj5j_1.i6vQp9Y_suJOBohwR4OWS39AHS D9klTmR.O4_elru8eDg7aTxFA339pwE_BPPS2eoqynBihQL4sQ5pS.buqyqudEd6WK3mXQJ3wO.W 5ImIkgkGJ1I9dmiumqu4W2sWqYlewmGhUEIJ3vBlAQnVTLMiR2OfaoyDZVxqQXk5v2M5e5bJMwer JunTY6fJPCDiqrxzdU3ktWrCcDBu67VY5DZLKbCKW.oXSic68ooRR.BmXgacT5gcYNAEytFULn5R m4SMWf3iXS4WItI39_ogsK7vtNK0QUh1lOlzcQ2huOFb0QolmtYaWQT5t1yfUO09lKXQTXGnhhiU Tl6ENcDQxCI5AS9b8TlffReagkNmlH2yijlvuEpAcv_Y9YUF.H1nSPmHMukc2mGbfwPgnB5bNd0V Kuoi4nGGKyj3LA9PjAv_m3sVgdP7ZpSVHNc7xcf414u7i9Rf778P8GHR8xGKnJobRH6tSpovb8HO r9lk7vRsm.7a0w7sE5TtOB_M5PuwG_WlBFsrv6_v6ao51b1Q88ZoMaZuw5.2cRYaslv3gPzVg5b8 tbQQPSVqjjov4adgE0nPwO5VDM8VA5pJZ3iyBti_.Lq3OS1vieVtkMWAyWXWYRafloYMX8oysUKJ z_Qh0DuhA9Trc3D2t3zMZQvPoKqGjKoKhkz0dc01C0BTOSOp1RcXR2eXA7lmfHONdqJH28Tc4vkS 73N9297EJI.TfFsj_8xwB2jp4r0c2iIx2MVjrgbQ0WY4Rgqaxe5V_C46ruuDCpZPtqtHI1Ac4Ya7 jvRsOlbw7oF1v1zu8CGbCG0tO6uqCjtiwHRW1fk5fZ6jz75VVg04e9nhmyEVQ6q0Asz3VZyIq5qF qajcgeDmM7EkUIqibUhke7dRRk9lS6wlLtDGx99XWhmGa9LXXyA0ZOf5jP02Rymp24KMkAh9vBZo JV5tZIqA__2KUy5fpCgbS4kBkH3JdsRdYHNy2JrMqoEPsHJIB26bP5y4vKyYKqyHW0wQt0UEE6Ng pBopsgzZ6VbysOHQAZB0VAVZMMu5BnDPedajukRYExuKWkg6uek3miH3OJ2qabbIrYM80II_7Ze3 uf5L04.R55PaDWSSHYZS75IBMqd_SydkvIPjADDceOnKoT1Ad2jZQH_qYlkdZTN4PuFKbP8xxEWs cukWjuNtChFDBBN2GO3goM0o5HwmbSCGaWdJloUH0zQY2dv3yFsZo73PaoZAk1.oNaTYzsQI8fDu ZhEXe7aQrN7ktGC.Tnwba1nudXF9Dn.ZPWLmF2MIBNIiKUd332aKGzROfstOdxJsyjaArFMaa9WH CP0qwb.sg2pEENvC7Vfd0NsFVLhWbKlkwGWXOomzJT5DJZzNBkIy6jKt6IzrL3.UZSlVo8qJ1J3Q J6oUyScEH6gi5tkx0m66kSFnKR6KebES3D8jJCcgnbUgJIG1DfxNO2vgeBnJZDNMcCBiKghimqqK ZV8w46NzhIf4sNfLvzSDz_dNkZt9hvrqtY.3PGAycgwPaTdw7gnnJu5.cqtasCJgu8RoJP2L0xYT E0p5Rf3DJp08HfOlI.2nRm.ST.bLznJKm0IyZ9OpKnIiemL4XDsIqh5p3ovSfTADbgSMKtwsiznb Z0ecXZ3AX7qdGY7SnB30sW0P6nTLYSO583HTFdIZUMQcLQZPkcyOXey2BVbMJYADQlCH2mIaUy_l 08JMPHqjSrUR4lX6r8h7nrbSQjLZTBwKa_ElQRww19bIymY.vBUS8RvAUZrL0G18_DRNl4G6ctot TCyDM_m_3IjQS_euMMXWi4llNi.6gNgzxCumYmtjzdyphyY1FIw4P4.LAjM6d0W4QJZyCHWkl.J. D137TP6hvqXycxtHdFgbD7Q9Y1nZ.vanN2MIhZ854AKrJgLFQn8zKZYQ2ZLyiFWJNXjcAvYS_Y1q gQD9yllYyORH_9NXB44sYuxQmXN3ywmVBazkopmL_dxCfbHvpffRarxlhCzaLCM65Uyfwuee6wHU - X-Sonic-MF: X-Sonic-ID: 948c3b7b-76de-48aa-b8a2-26b52881f135 Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Sun, 4 Aug 2024 06:08:12 +0000 Received: by hermes--production-gq1-5d95dc458-5j27b (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 0a5476f81707f3d349f20b5b11cf82bb; Sun, 04 Aug 2024 06:08:09 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Any known way to build devel/llvm* ( such as devel/llvm19 ) with --threads=1 for its linker activity during the build? Message-Id: <4FFD603F-E67C-4B62-B91B-8BE365EAA050@yahoo.com> Date: Sat, 3 Aug 2024 23:07:59 -0700 To: FreeBSD Toolchain , FreeBSD ARM List X-Mailer: Apple Mail (2.3774.600.62) References: <4FFD603F-E67C-4B62-B91B-8BE365EAA050.ref@yahoo.com> X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.78 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.78)[-0.785]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; APPLE_MAILER_COMMON(0.00)[]; MLMMJ_DEST(0.00)[freebsd-toolchain@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.84:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.84:from] X-Rspamd-Queue-Id: 4Wc8JH2QGVz54Zg My recent attempts to build devel/llvm18 and devel/llvm19 in an armv7 = context (native or aarch64-as-armv7) have had /usr/bin/ld failures that = stop the build and report as: LLVM ERROR: out of memory Allocation failed (no system OOM activity or notices, so just a process size/fragmentation = issue, or so I would expect). On native armv7 I also had rust 1.79.0 fail that way so --but = aarch64-as-armv7 built it okay. I'm curious if --threads=3D1 use for the linker might allow the = devel/llvm* builds to complete at this point. Similarly for rust. (top = showed that the ld activity was multi-threaded.) Note: The structure of the poudriere-devel based native build attempts = is historical and it used to work. Similarly for the aarch64-as-armv7 = based build attempts. For now I'd just be exploring changes that might = allow much of my historical overall structure to still work. But I = expect that things are just growing to the point building is starting to = be problematical with process address spaces that are bounded by a limit = somewhat under 4 GiBytes. Native armv7 was a 2 GiByte OrangePi+ 2ed (4 cores) that had at boot time: AVAIL_RAM+SWAP =3D=3D 1958Mi+3685Mi =3D=3D 5643Mi and later had "Max(imum)Obs(erved)" figures: Mem: . . ., 1728Mi MaxObsActive, 275192Ki MaxObsWired, 1952Mi MaxObs(Act+Wir+Lndry) Swap: 3685Mi Total, . . ., 1535Mi MaxObsUsed, 3177Mi MaxObs(Act+Lndry+SwapUsed), 3398Mi MaxObs(A+Wir+L+SU), 3449Mi (A+W+L+SU+InAct) The aarch64-as-armv7 was a Win DevKit 2023 that has 8 cores and: AVAIL_RAM+SWAP =3D=3D 31311Mi+120831Mi =3D=3D 152142Mi So lots of 4 GiByte or smaller processes would fit. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Aug 4 21:00:19 2024 X-Original-To: toolchain@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WcX5c33lNz5T1Js for ; Sun, 04 Aug 2024 21:00:20 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WcX5c0QSRz4f8n for ; Sun, 4 Aug 2024 21:00:20 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1722805220; a=rsa-sha256; cv=none; b=nirUxxTP3zgGwj+zafL0MbgqQxGBqaWjZVuxtNEhGD7ymIAroAXfIjlhrJSUGWA/9XRpLm bp0O0RJHy2pEhnZvGRtpqnwFZstkxRbAFFC66x1uIBoN1Z+vekLXHjXZ9+SQmaNSP9EUKQ 2JALE+l4mCPivmC1F0VNyNzm48BFNQuPQF9CkIw2ONsflAOL5S1/e6euaWqUeO4ugTlQqK doQLXfswHJBU4fpfoH+ddMUWggvGY1NxlQElvZz0oW0inbToLH3q1pgrn+ZimauMIr3B7p JR9Sr9Ezny5CukfhIQlK9BIkiB0p52YGdRIJ5bnDPpMDpaBOSfSOujN+ydo6rw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1722805220; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=5/cABgc9Z8/0HPTluVE9U2/2IC1sfaXeGq4qk678Nn4=; b=iBqSYMPeI5AQeue3mRDQGXGGUeEIi6nDWze3Kjj7eJt5f3zFvMKZODVJI4rp/KeBPoLQ6F Puzx3ye34rd6Pfg7/Jo0tTX6V2fApK/oYPI+p6nWj4zXLfUMvXUOkgxw63Sfhigge7NaNd zo1qchfwh0Ub1QwLRjiT6nXV5NmViltm+Enj1M4+L3/Gj1CuRQjrQ9xTxxNVrTWVtzuSzN 9BdSoNb4T7+3cUdI9xyETE0C1L4VIf0He7HvKCrC+AgXZ2MLC381o9fz3lpvKJtucCehcA q0MIBoSoIyCOFq0LerbUDm8OTiCGQ1YCB+BexRm4LxQ24Xsu9k+L2P8z/RQFdw== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4WcX5b6znYz19TT for ; Sun, 4 Aug 2024 21:00:19 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 474L0JvN083688 for ; Sun, 4 Aug 2024 21:00:19 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 474L0Js2083687 for toolchain@FreeBSD.org; Sun, 4 Aug 2024 21:00:19 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202408042100.474L0Js2083687@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: toolchain@FreeBSD.org Subject: Problem reports for toolchain@FreeBSD.org that need special attention Date: Sun, 4 Aug 2024 21:00:19 +0000 List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="17228052193.3CFBb6.79997" Content-Transfer-Encoding: 7bit --17228052193.3CFBb6.79997 Date: Sun, 4 Aug 2024 21:00:19 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- Open | 236165 | crash in malloc with ld.lld and -Wl,--export-dyna Open | 261341 | clang-13 runs out of memory on the port math/open Open | 263870 | cad/horizon-eda: Crashes clang 13 on aarch64, amd Open | 271624 | emulators/qmc2: clang crashes during build on {12 Open | 192686 | Segfaults using combinations of -pie -pthread -lm 5 problems total for which you should take action. --17228052193.3CFBb6.79997 Date: Sun, 4 Aug 2024 21:00:19 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" 
The following is a listing of current problems submitted by FreeBSD users,
which need special attention. These represent problem reports covering
all versions including experimental development code and obsolete releases.

Status      |    Bug Id | Description
------------+-----------+---------------------------------------------------
Open        |    236165 | crash in malloc with ld.lld and -Wl,--export-dyna
Open        |    261341 | clang-13 runs out of memory on the port math/open
Open        |    263870 | cad/horizon-eda: Crashes clang 13 on aarch64, amd
Open        |    271624 | emulators/qmc2: clang crashes during build on {12
Open        |    192686 | Segfaults using combinations of -pie -pthread -lm

5 problems total for which you should take action.
--17228052193.3CFBb6.79997-- From nobody Sun Aug 4 21:31:46 2024 X-Original-To: freebsd-toolchain@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WcXpD07wjz5T4VV for ; Sun, 04 Aug 2024 21:32:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-21.consmr.mail.gq1.yahoo.com (sonic310-21.consmr.mail.gq1.yahoo.com [98.137.69.147]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WcXpC1ySfz4tnY for ; Sun, 4 Aug 2024 21:32:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=gAJYAihZ; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1722807120; bh=0GPM9MTbiDSsLhTOtKRVk6FM6riMipDVzpTzZYGaUio=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=gAJYAihZtyGYsnAN/CuOOtatE+D5wyXuKMJ7lCswfzmXAPqHOEvR9lj/iWagHpqNDWzgfqXB7/Dxb8BabIQ3LWNBcH5vFuJO7eEmHp3hmT718RDOAhJn5opK1ym3Er6TAXYQUjKvvfhdWVfq2IAmcbBc9clQhLci6ORgpSOE5bCEc76y/myxfAMsY7lSb2kG8HMPzTWR/pue75KHNOdtuCNaGZALyzsytjpt81Hp+qcr3iM1x0f5tJ5mwrlYcrsRk+PWoROBeHs9qL9vplVhD1syGfjZ2EfMfqRs9MWgSBGONTTmYNoPsw9mqfDrQpeGB+n5Tr+FqTfSZVzSMl+mfA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1722807120; bh=RN44O14VJT1wk6Yf2eHxSIeMPM3rBelnkeh30dW014v=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=qmkKhfYnjGcbMBGZ+i69cNC/nxoLeMvSaSPlwUcAPVrmUHyr4bB/YTUPE08lCLZvah7ewkkADJh1BePCNMYVJc6ezTY43uzD/Mv6gnEP8DbITRONX2Xej+A+eYRDLJgtYS00LCOFmAZcQ17XGSJ0I3W/PNoR7ccCBF6I19vBs8jQxNW1ubxsxjS8seUaTnykQhCQpkEsgPjYxOT1SYqa6vUSjy5sB+7xh6609RU4mZc5CkxBtsIQxEeh0lQov/d+fXn7VghJQNfZNnMhJ0Fz2zKxM2AmbwUt7kTBesjJtXQ+9GTYtLIIG8aW7u0RDtwiT7a/p97CiNVaKuknBHSYeg== X-YMail-OSG: bazRWWQVM1mnrYvvjgOJy68zUDSlDGGXRM1EsLLZ07TBYJItwGpe3O9rhZhc3rz 4Tl02KoX19X0zhfJ7u9ftutjBH0sFT13E74UJtqtosntHuDWuabJQQlNc3ia7SCSKUjjqFt3gXGr jonLBGhS_DKru5vkFedEe7oGfBiWbcgAfjzOuEvsPY0XYBVyHfyuRTySaMtSMRYp0Pw6VhSBHyi6 g9gPLlcUD9V9D295szpwZ6aYZ6DRlIjJHgDLA1XYpQfuih.DULSch1BD54D3z9fy1.AkUwoR7kEJ J5B60gI81HFLZ8p9ZjYyuyhY8bHP3EayzA0Hq4.oSuHzVjXf_wmGecsvwlPapzKvuvpW3VZyuTPS hYrir.bDJALXIh3WJPdlkNZmAq7LV6SEGHXwrGHT4eKTT9HLP1kBaRKHr6eVLM95blgiyk_FrzFd EVJYHdfRVEI824brfkNppYpbbcpokl.SM8QB_BQoUDNOGKPlkyBq2w5CsMZESVN6d5qYY_uNSFWH CEDiJRZI4er5I8w8gXkLf5LUoSlh530GDsC3kfNqiSS1yq2wMawfeA5W_OVpjmp5AvR4LvUV351. Lt8J4YBapMt2pW5YWK2yXcwxDovjHd5HQUYs8fr_uS_jpfYxg6FWNXMFuDE.x753oNUThpH2eGGZ DdHNaD9z0a8s4ZsPAWy_RoRfJp9ZLhFDJjedc71E7anZbZLsURGBnhMGdjdYb0lDRvQpoRhs.Xgr cl0idoleEAnSOpJTIVKJf9.E3CLJVE7_7hJ7AZ8bxKLwzPog0wjce1WZTEcSeWLsUwZ0AygOVYkZ DaDwoBpqGv23dQLJl7rxZQTOd4ukl1CO9oEdk1iebQtiyxzjOemcyb_2JWONgYhy2T1Pjq5MzsZ9 7E4ZKJfNBxpcW8QaJHOrh4dwL4ykLDNvysTVeqQiXj34yk1SR8vi.tc62n09WbePxIN824zKKvTk o7CcwZJxjdhkbnMRUHCu1r7G5f94fjNiY82lPM2zZ6_0JUrlCaEcOLf9ILCXEqZX9HO3XOzos.Eu 37oXpXilMaBnDIweTLB53HRRfZCf.tVTZ20EOOXMOB3yIj2rAclugvBeqTVKfvm2T4r_ISNMZGq9 1.0bu2yCQjFcBHq9uev3QphdBdOH2cCQnwnouapN1RCZjNNyseQnUYlFXmjlhq2JABVZdq91bhSw TtTNJ7_tdFTcv3Z1SuTgrrCJFfp2trY7DjNPUFarj7ol_BVJp9kt9DLNMdqerSsdItG4Dsx7afsY Tm2MJUf9SR6xr_.EMd99pGDRZX3lzB8Zf9j7tfIA6olMN0q91PMaWtlpeVCeOqzHMVFW6JlQohrU QhkvC2etE6Z1DHTq6foX_v6HcmlllDpy3hvSdV93hskGwmrk4n3emYNzmR30.7CKwxCEC9QP1Mb5 SDxEKjQn.8H793qEdVLJ7FmZutdtJn1Q.I4MVXOUGMurnPiZANPwNp7v1cu5J445s4NNGyff3.TY ru6hAzfk2Msh6xfcZsrHw25tfXAYwvaDYOflzGVUt7nggfe2TbA38t5Lw9be7tTKCuXNTy9lCaAv 0j4Meg3tIT_aO8JR1HMBfR_xAZdIkDq.Rg8WiEbrv14rQFsxrjMC6PQ0PeOvAaz..drcNIopXxms ADB195_aLZwW6kkVltY9MbEYNBK7AXsc58I.XfNhEW305bRjpp4JjNOp_xmkQZwJaIfB4_7etqNW lnx3lxS3rHnT7KiUJhILNkdCN8O7Z1BnNzozcdw7wETNxCgT9ANCHXcYUDfhl8YzxuVNLJV4gvzg eS8jMmKAqgQBg8utzjPCx7GgTa3coA46LLJfFXuY1w_So8cFXJDX38KzJyVTIjbglrKWRJ5nKhzN IaimIlu_HY3SL1tpYuyD2z4NtelD.x0nhke6woZwbc6gRl5367CLcpRETkM.eZuWNw0WAdx63YQ1 XNtgnnUXFW15egBt49g0_0c.HYUQ4v16a4W58nwc5tQ8xd7g7oUrK.5_XJwRntiWARBaPbj4XF1z dtfGXRkzX24QXvjiWECUb_KijWNZKAFa.H4MR4rZdZdAY09uRRxMR.KVpgwYfhGK1cBvjktwn8xi 7SbuJI1IIbAXEKLZYvENd.e1PRzhw98iJbiz_9dEXW7OATR64w_Yn2FGpyTa4B_VGwdibY7M5IEH 4T8P01sfuBedkWrq1scCowyT9r4Mxi33H2JQO6YYE.BlDhv5EfuhxVXrg3UZNK5BYN4pvtgHc8he j0i19RPfDMrR3RJaJ89ny4Ax0kkrL_eXKbpiF3pNcCbCvm2lK2C_bMUb27wt_WXn23KVIB8dWVws - X-Sonic-MF: X-Sonic-ID: 650892d7-656d-4f0f-ba3c-19b4b0ab02d3 Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Sun, 4 Aug 2024 21:32:00 +0000 Received: by hermes--production-gq1-5d95dc458-4hqnr (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 0470da286e7b568efe5e6afb36867c85; Sun, 04 Aug 2024 21:31:57 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Re: Any known way to build devel/llvm* ( such as devel/llvm19 ) with --threads=1 for its linker activity during the build? Date: Sun, 4 Aug 2024 14:31:46 -0700 References: <4FFD603F-E67C-4B62-B91B-8BE365EAA050@yahoo.com> To: FreeBSD Toolchain , FreeBSD ARM List In-Reply-To: <4FFD603F-E67C-4B62-B91B-8BE365EAA050@yahoo.com> Message-Id: <82E78798-C376-45C4-80FE-96AD14229419@yahoo.com> X-Mailer: Apple Mail (2.3774.600.62) X-Spamd-Bar: -- X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-toolchain@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.147:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.147:from] X-Rspamd-Queue-Id: 4WcXpC1ySfz4tnY On Aug 3, 2024, at 23:07, Mark Millard wrote: > My recent attempts to build devel/llvm18 and devel/llvm19 in an armv7 = context (native or aarch64-as-armv7) have had /usr/bin/ld failures that = stop the build and report as: >=20 > LLVM ERROR: out of memory > Allocation failed >=20 > (no system OOM activity or notices, so just a process = size/fragmentation issue, or so I would expect). >=20 > On native armv7 I also had rust 1.79.0 fail that way so --but = aarch64-as-armv7 built it okay. >=20 > I'm curious if --threads=3D1 use for the linker might allow the = devel/llvm* builds to complete at this point. Similarly for rust. (top = showed that the ld activity was multi-threaded.) >=20 > Note: The structure of the poudriere-devel based native build attempts = is historical and it used to work. Similarly for the aarch64-as-armv7 = based build attempts. For now I'd just be exploring changes that might = allow much of my historical overall structure to still work. But I = expect that things are just growing to the point building is starting to = be problematical with process address spaces that are bounded by a limit = somewhat under 4 GiBytes. >=20 >=20 > Native armv7 was a 2 GiByte OrangePi+ 2ed (4 cores) that had > at boot time: >=20 > AVAIL_RAM+SWAP =3D=3D 1958Mi+3685Mi =3D=3D 5643Mi >=20 > and later had "Max(imum)Obs(erved)" figures: >=20 > Mem: . . ., > 1728Mi MaxObsActive, 275192Ki MaxObsWired, 1952Mi = MaxObs(Act+Wir+Lndry) >=20 > Swap: 3685Mi Total, . . ., > 1535Mi MaxObsUsed, 3177Mi MaxObs(Act+Lndry+SwapUsed), > 3398Mi MaxObs(A+Wir+L+SU), 3449Mi (A+W+L+SU+InAct) >=20 >=20 > The aarch64-as-armv7 was a Win DevKit 2023 that has 8 cores and: >=20 > AVAIL_RAM+SWAP =3D=3D 31311Mi+120831Mi =3D=3D 152142Mi >=20 > So lots of 4 GiByte or smaller processes would fit. >=20 Absent finding a way to get --threads=3D1 to be what is used, I made the following crude way to test, built it, installed it in the armv7 directory tree used for aarch64-as-armv7, and then started an aarch64-as-armv7 test of building devel/llvm19 to see what the consequences are (leading whitespace details might not be preserved): # git -C /usr/main-src/ diff contrib/llvm-project/ diff --git a/contrib/llvm-project/lld/ELF/Driver.cpp = b/contrib/llvm-project/lld/ELF/Driver.cpp index 8b2c32b15348..299daf7dd6fa 100644 --- a/contrib/llvm-project/lld/ELF/Driver.cpp +++ b/contrib/llvm-project/lld/ELF/Driver.cpp @@ -1587,6 +1587,9 @@ static void readConfigs(opt::InputArgList &args) { arg->getValue() + "'"); parallel::strategy =3D hardware_concurrency(threads); config->thinLTOJobs =3D v; + } else if (sizeof(void*) <=3D 4) { + log("set maximum concurrency to 1, specify --threads=3D to = change"); + parallel::strategy =3D hardware_concurrency(1); } else if (parallel::strategy.compute_thread_count() > 16) { log("set maximum concurrency to 16, specify --threads=3D to = change"); parallel::strategy =3D hardware_concurrency(16); Basically, if the process address space has to be "small", avoid any default memory use tradeoffs that multi-threading the linker might involve --even if that means taking more time. We will see if: [00:00:33] [07] [00:00:00] Building devel/llvm19@default | = llvm19-19.1.0.r1 still fails to build as armv7 vs. if the change leads it to manage to build as armv7. =3D=3D=3D Mark Millard marklmi at yahoo.com