From nobody Mon Jul 29 16:01:46 2024 X-Original-To: freebsd-arch@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 4WXjm93qSnz5RW3v 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 4WXjm92NJtz47dw for ; Mon, 29 Jul 2024 16:02:01 +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: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@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: 4WXjm92NJtz47dw 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