From nobody Thu Sep 11 16:53:37 2025 X-Original-To: freebsd-current@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 4cN3YD6nVkz66vB8 for ; Thu, 11 Sep 2025 16:53:52 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ed1-f45.google.com (mail-ed1-f45.google.com [209.85.208.45]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cN3YD2vq0z3S0n for ; Thu, 11 Sep 2025 16:53:52 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-f45.google.com with SMTP id 4fb4d7f45d1cf-6188b5ad4f0so1609352a12.0 for ; Thu, 11 Sep 2025 09:53:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757609631; x=1758214431; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=7JfhVshJ6wzy2HGP4lP1YcnCWeWYbPztgFufGhPyqhI=; b=Y4NcODwCH2VjSI1AxcqlAfTRnZlI9UfVssDnubfd10wA/gXGhghnUvWW97TMDZ2YWS okaSAVjpXaXLavR7wuT8SALXyC5edC8qUkuV6Ck1jV0EZ5X0tiNqbHSnM1x7jidumwb/ vrbWw5FJBhhosWdlQMZeJcyBoJrFvzWkMAyoOQ4WUW24I7lrtn5jau96G2ekdmomPtFf ZrcnTaWekM8oclEqaedJngWz8mOep4hao1lt8Ur5CTOKv9+RGZV1HmVhLjdY7lQA87sI 96hdrXREEZxErKkZ2j3o3l9t+QPZ0EL5s8LGcHIf9Rj/Lsg7acBXWQ1NUGU9v4Ej0ncx Rq5g== X-Forwarded-Encrypted: i=1; AJvYcCXgknQiG4P0hzyEUnwocZ+rkxKjrWDKXUBb/WBv/tZ8UVM59WN+qVJWdoRaoAOkeSibrwKSv5gHvLpA+SLIyig=@freebsd.org X-Gm-Message-State: AOJu0YxhHZ4NomkA4QulM53u7DJ0fV1lHgprVcN6yKbsGMZGMQiU2Rov /b4llVwMfyDlPw9sCOk8WVsKsDg2NT9QD+2+CQ/2TxokYT6tbUc9BYxmA703gJV7Fyjt646cilj 63Uvws9PesIZYt2T6o/PvY2EJ7MSgh0Q= X-Gm-Gg: ASbGncvNLHU1FbcBXGNTrpG0lUQ9ReBTTXPQGVm1s+7IbWBSx5UhFt0YArDNwU5cpZa /O5EmTMxsb3CC3fWYWFo6vyJa17Tswj68G3fyglMcrQjyBTwcVyNINm2rb1EXNsPspf+L7lxgBi uygmrVKw29nIhrA7Rz22tXJrcxeGwGEMzzFud2WHmVszmErKLm6ONv6YC4m60JJ9dJZh65M3x+M meyVe91XqsZvJmstQ== X-Google-Smtp-Source: AGHT+IFPLk/oxkdcGla/lVVMlplW6GnpX0ac1LXa385a2JPNt7dSFJjn1G/ByP1F6LROdq66NR6HzSo+wzgWSSbIRaA= X-Received: by 2002:a05:6402:354f:b0:629:3f9d:b06c with SMTP id 4fb4d7f45d1cf-62ed866c3c2mr216996a12.33.1757609630583; Thu, 11 Sep 2025 09:53:50 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <1F6A4621-1505-4F78-97C6-85EA556B2165.ref@yahoo.com> <1F6A4621-1505-4F78-97C6-85EA556B2165@yahoo.com> <86bjnhi7s2.fsf@ltc.des.dev> <86zfb1ghj7.fsf@ltc.des.dev> In-Reply-To: From: Alan Somers Date: Thu, 11 Sep 2025 10:53:37 -0600 X-Gm-Features: AS18NWDk-AY2APOz4L4eTnut7r0UO9TDrv78w7U26RfzJrlaovWmWVym2ZtS1k4 Message-ID: Subject: Re: git: d549de769055 - main - libc: Remove readdir_r(3) [This broke building rust 1.88] To: Warner Losh Cc: Toomas Soome , FreeBSD Current Content-Type: multipart/alternative; boundary="000000000000af4e88063e896163" X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cN3YD2vq0z3S0n --000000000000af4e88063e896163 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Sep 11, 2025 at 10:10=E2=80=AFAM Warner Losh wrote= : > > > On Thu, Sep 11, 2025 at 9:48=E2=80=AFAM Alan Somers = wrote: > >> On Thu, Sep 11, 2025 at 9:45=E2=80=AFAM Toomas Soome wro= te: >> >>> >>> >>> On 11. Sep 2025, at 18:10, Mark Johnston wrote: >>> >>> On Thu, Sep 11, 2025 at 05:01:16PM +0200, Dag-Erling Sm=C3=B8rgrav wrot= e: >>> >>> Alan Somers writes: >>> >>> Dag-Erling Sm=C3=B8rgrav writes: >>> >>> Tell that to the Rust developers. They have been repeatedly warned >>> against using readdir_r(3) for years, as far back as 2016. >>> >>> Have they? Looking at rust's github page, I see discussions about >>> using readdir_r on Fuchsia and Linux, but nothing about BSD. >>> >>> >>> If you look at these tickets, there are people pointing out that >>> readdir_r() doesn't work correctly even on platforms where it isn't >>> formally deprecated. The Rust developers chose to fix the Linux case >>> because it produced a link-time warning and ignored the rest. That's o= n >>> them. >>> >>> They also seem to be providing their own prototype for readdir_r(), >>> which suppresses the deprecation warning they should be getting on >>> FreeBSD 15, and turns the issue from a failure to compile into a failur= e >>> to link. That's also on them. >>> >>> >>> It doesn't really matter whose responsibility it is. If rust can't be >>> compiled on FreeBSD after a FreeBSD change, then it's up to us to fix >>> it. The purpose of FreeBSD, like any other useful OS, is to run the >>> software that people want to run. >>> >>> +1 to Alan's request to back out the change for now. >>> >>> >>> >>> How about putting up pull request for rust to fix it?;) >>> >> >> That should certainly be done. I'll try to do it this weekend, if I hav= e >> time. However, the need to revert this change will remain. FreeBSD 15 >> needs the ability to run both current and old Rust toolchains. >> > > So for current rust: it needs a pull request despite the revert. Rust is > simply wrong here, due to their choices, and that has to be unwound in > their code base. That's non-negotiable. We learned with the FreeBSD11 ABI > troubles that we must be more proactively involved to see changes through > to the end with Rust or the long legacy that creates problems for us. Her= e > the risk extends beyond the rust ecosystem because we must continue to > expose a broken-by-design interface to newly built code. > > Old rust toolchains run fine on 15. Regression testing can be done on > those, but that's not a fully desirable answer. But t's only previously > built rust toolchains that still run. Newly built ones do not. That's a > problem. > > So, for building these old toolchains anew, we can't support them > indefinitely. There needs to be a transition period for building old > toolchains. We're in that now that the base change has been reverted. But > the question is: How far back does Rust test? How old are the toolchains > they do A/B testing against today? Is it 3 months? 6 months? 12 months? > That will tell us the timeline we need to support this configuration. Giv= en > both the importance of Rust, and "history" we owe it to ourselves to be > intentional about what we do here. > > Warner > Rust has a clockwork release cycle. A new beta and stable release are published every 6 weeks. Sometimes a patch release is published based on an existing stable release, but that's rare, and it always follows the stable release within less than one month. But after one or at most two patch releases, there really isn't any more development of that version. So I suggest: * Up to 6 weeks from when the PR lands to when it reaches a beta release * Another 6 weeks for it to reach a stable release * Another 6 weeks maximum in case there's a need for a patch release That's only 18 weeks. And we can safely round it up to 6 months. But another problem is that FreeBSD 15's GCP images have been broken for months, which makes it hard for anybody to do CI on FreeBSD 15. IMHO we should fix our GCP images before we start the clock ticking on readdir_r. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D288817 --000000000000af4e88063e896163 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Sep 11, 2025 at 10:10=E2=80=AFAM Warn= er Losh <imp@bsdimp.com> wrote:=


On Thu, Sep 11, 2025 at 9:48=E2=80=AFAM Alan Somers = <asomers@freebs= d.org> wrote:
On Thu, Sep 11, 2025 at 9:45=E2=80=AFAM Toomas Soome <tsoome@me.com> wrote:


On 11. Sep 2025, at= 18:10, Mark Johnston <markj@FreeBSD.org> wrote:

On Thu, Sep 11, 2025 at 05:01:16P= M +0200, Dag-Erling Sm=C3=B8rgrav wrote:
Alan Somers <asomers@freebsd.org> writes:
Dag-Erling Sm=C3=B8rgrav <des@freebsd.org> writes:
Tell that to the Rust developers.=C2=A0 They have been repea= tedly warned
against using readdir_r(3) for years, as far back as 2016.<= br>
Have they?=C2=A0 Looking at rust's github page, I see d= iscussions about
using readdir_r on Fuchsia and Linux, but nothing about= BSD.

If you look at these tickets, there are people po= inting out that
readdir_r() doesn't work correctly even on platforms= where it isn't
formally deprecated.=C2=A0 The Rust developers chose= to fix the Linux case
because it produced a link-time warning and ignor= ed the rest.=C2=A0 That's on
them.

They also seem to be provi= ding their own prototype for readdir_r(),
which suppresses the deprecati= on warning they should be getting on
FreeBSD 15, and turns the issue fro= m a failure to compile into a failure
to link.=C2=A0 That's also on = them.

It doesn't really matter whose responsibility it is.=C2= =A0 If rust can't be
compiled on FreeBSD after a FreeBSD change, then it= 's up to us to fix
it.=C2=A0 The purpose of FreeBSD, like any other usef= ul OS, is to run the
software that people want to run.

+1= to Alan's request to back out the change for now.


How about putting up= pull request for rust to fix it?;)

=
That should certainly be done.=C2=A0 I'll try to do it this weeken= d, if I have time.=C2=A0 However, the need to revert this change will remai= n.=C2=A0 FreeBSD 15 needs the ability to run both current and old Rust tool= chains.

So for current ru= st: it needs a pull request despite the revert. Rust is simply wrong here, = due to their choices, and that has to be unwound in their code base. That&#= 39;s non-negotiable. We learned with the FreeBSD11 ABI troubles that we mus= t be more proactively involved to see changes through to the end with Rust = or the long legacy that creates problems for us. Here the risk extends beyo= nd the rust ecosystem because we must continue to expose a broken-by-design= interface to newly built code.

Old rust toolchain= s run fine on 15. Regression testing can be done on those, but that's n= ot a fully desirable answer. But t's only previously built rust toolcha= ins that still run. Newly built ones do not. That's a problem.

So, for building these old toolchains anew, we can't s= upport them indefinitely. There needs to be a transition period for buildin= g old toolchains. We're in that now that the base change has been rever= ted. But the question is: How far back does Rust test? How old are the tool= chains they do A/B testing against today? Is it 3 months? 6 months? 12 mont= hs? That will tell us the timeline we need to support this configuration. G= iven both the importance of Rust, and "history" we owe it to ours= elves to be intentional about what we do here.

War= ner=C2=A0

Rust has a cloc= kwork release cycle. A new beta and stable release are published every 6 we= eks.=C2=A0 Sometimes a patch release is published based on an existing stab= le release, but that's rare, and it always follows the stable release w= ithin less than one month.=C2=A0 But after one or at most two patch release= s, there really isn't any more development of that version.=C2=A0 So I = suggest:

* Up to 6 weeks from when the PR lands to= when it reaches a beta release
* Another 6 weeks for it to reach= a stable release
* Another 6 weeks maximum in case there's a= need for a patch release

That's only 18 weeks= .=C2=A0 And we can safely round it up to 6 months.=C2=A0 But another proble= m is that FreeBSD 15's GCP images have been broken for months, which ma= kes it hard for anybody to do CI on FreeBSD 15.=C2=A0 IMHO we should fix ou= r GCP images before we start the clock ticking on readdir_r.

= --000000000000af4e88063e896163--