From nobody Thu Sep 11 16:09:53 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 4cN2Zl6tbHz66rhR for ; Thu, 11 Sep 2025 16:10:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) (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 4cN2Zl2hPTz3HB1 for ; Thu, 11 Sep 2025 16:10:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1035.google.com with SMTP id 98e67ed59e1d1-32d3e17d95dso620309a91.3 for ; Thu, 11 Sep 2025 09:10:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1757607005; x=1758211805; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=yt75sS8sOE4UTq3i9m1l23OXhcl3oHzd2uChoEbVXHU=; b=BjwvOUW27wUNDXXKwsreLbaPB61jQTRmMOH9R8zxgDqoP0A8xzJwQ3J7taBtH6wY43 H8Zc/97jLxAsqYRO96eveTUTgE5S4f592NqVkGze56Om2oKQrMMPT9gfsAh8F6DWgE6v nbj6c6Cyv146hkriRfW5TV87Cc37Wm+4oc/7slQ5/LgGBlzIy0FM3x7mKzuC70ZnlX2S Ew7CYNrkxxVIdZBbcSt38c4fzTdRIC2q7GWltRnGh07FFosINJXtR+BVrBQJ8x1/M5wZ jJhC/kl3tbdkHSAJRLaYxw5rYWDhF+L1ylZUEMfkirCCyO4OF8ABOsydNtUwzisK8t+A I5Rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757607005; x=1758211805; 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=yt75sS8sOE4UTq3i9m1l23OXhcl3oHzd2uChoEbVXHU=; b=NG9TwqjjT5ao9AUczhGaEz9fJiDRTB1gvY8tWG09/PtMTfgQLjdabLPi2rWRjc7/lC r65YNnXvAugCa17xNIdBRg1q3Kj/vsqq0jb/Qv6JeRBoo7s1rV9O1LdM7JLAjFrF/fi7 97HB1n7H7vPRoy1b4a9C0e4dLPja9GgJE9qIH846pyJgjnffMBYW3Fda/0vvfja3Uw6K UJIi0ssvWtRcOXBHWgZpT2kHfGpaBchcl7pYWuCK+ZIegv+czAUa6Hftpn8kggN/ug3m IfPSG+pBqX+X2Cnecv5UMaoidbAzVFj0gZ+3/GhcT3AzreqLdvQF/CDSPxZSWT0lIFMA BU5Q== X-Forwarded-Encrypted: i=1; AJvYcCWsVDWrGiLcAaBA3qLe0CrUwywfH96jD2PKyx64SQybM5xp/ebaFLEknonXA8AfK9LD/AvhgXoHao+Rs7HDCro=@freebsd.org X-Gm-Message-State: AOJu0YzuMw9B6BHp92pwm0IRmJ4X1tS2UMeedlRrvpeLvtcAcSmOzbrM x0cFhjYJj/uImgupgIYfvP2O3+SGDTP0MKysA8tMWYaKPrxh7VGXsUOBleDiGphwKRjyiMcQc/D Jx/u8PCBNlVu2XXZHRwAbS+flWy0GXdQPA/2vLeujp1KEmvLHbjBj90E= X-Gm-Gg: ASbGnctKFCfbDSLAMx2FDX0ZVbeGRpjYXPpF9EhgFh1D06J1jtW8Oh7rZTbAv3je7Xh zRQoYtbZ7GxE8nJ2Y7v3JUyTQWFBDHZDFM13+993QUWwfroBoivRv1GHwSLUdNBp5byxm70t3Jx O8onvaU/jOKdAYh8lMw9wc1Z+vJNz5p35mPL7i0Q9hPh03Hkw1gJSvSxTB6Rhw+5vC/fJj6GRaf iat5I6ttkRoI91s+uPlSeL2kmGT17LgLIdJ/k8= X-Google-Smtp-Source: AGHT+IHg6+/mNq0nrJECJBKwi3yPl9Cqwf029+2zM7jvQzHHTyb8PdacuU935Gwz4uGxPFW3BPxxQc7GuGktCZKzgMs= X-Received: by 2002:a17:90b:58cd:b0:31e:c95a:cef8 with SMTP id 98e67ed59e1d1-32d43f8e89bmr22683387a91.32.1757607004559; Thu, 11 Sep 2025 09:10:04 -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: Warner Losh Date: Thu, 11 Sep 2025 10:09:53 -0600 X-Gm-Features: Ac12FXxl5P1K9rnS9UR-j5gBfyWxngZVpiB1p0lZn_hTfVk84s8FcgWxi-0IrdY Message-ID: Subject: Re: git: d549de769055 - main - libc: Remove readdir_r(3) [This broke building rust 1.88] To: Alan Somers Cc: Toomas Soome , FreeBSD Current Content-Type: multipart/alternative; boundary="000000000000296e9d063e88c5ed" X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cN2Zl2hPTz3HB1 --000000000000296e9d063e88c5ed Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Sep 11, 2025 at 9:48=E2=80=AFAM Alan Somers w= rote: > On Thu, Sep 11, 2025 at 9:45=E2=80=AFAM Toomas Soome wrot= e: > >> >> >> 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 wrote= : >> >> 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 on >> 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 failure >> 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 have > 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. Here 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. Given both the importance of Rust, and "history" we owe it to ourselves to be intentional about what we do here. Warner --000000000000296e9d063e88c5ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Sep 11,= 2025 at 9:48=E2=80=AFAM Alan Somers <asomers@freebsd.org> wrote:
On Thu, Sep 11, 2025 at 9:45=E2=80=AFAM Toom= as Soome <tsoome@me.c= om> wrote:

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

On Thu, Sep 11, 2025 at 05:01:16PM = +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 repeate= dly warned
against using readdir_r(3) for years, as far back as 2016.
Have they?=C2=A0 Looking at rust's github page, I see dis= cussions about
using readdir_r on Fuchsia and Linux, but nothing about B= SD.

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

They also seem to be providi= ng 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 failure
to link.=C2=A0 That's also on th= em.

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= 9;s up to us to fix
it.=C2=A0 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 pu= ll request for rust to fix it?;)

That should certainly be done.=C2=A0 I'll try to do it this weekend, = if I have time.=C2=A0 However, the need to revert this change will remain.= =C2=A0 FreeBSD 15 needs the ability to run both current and old Rust toolch= ains.

So for current rust= : it needs a pull request despite the revert. Rust is simply wrong here, du= e 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. Here the risk extends beyond= the rust ecosystem because we must continue to expose a broken-by-design i= nterface 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 toolchain= s that still run. Newly built ones do not. That's a problem.
=
So, for building these old toolchains anew, we can't sup= port them indefinitely. There needs to be a transition period for building = old toolchains. We're in that now that the base change has been reverte= d. But the question is: How far back does Rust test? How old are the toolch= ains 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 oursel= ves to be intentional about what we do here.

Warne= r=C2=A0
--000000000000296e9d063e88c5ed--