Re: git: d549de769055 - main - libc: Remove readdir_r(3) [This broke building rust 1.88]

On Thu, Sep 11, 2025 at 10:10 AM Warner Losh <imp@bsdimp.com> wrote:

>
>
> On Thu, Sep 11, 2025 at 9:48 AM Alan Somers <asomers@freebsd.org> wrote:
>
>> On Thu, Sep 11, 2025 at 9:45 AM 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:16PM +0200, Dag-Erling Smørgrav wrote:
>>>
>>> Alan Somers <asomers@freebsd.org> writes:
>>>
>>> Dag-Erling Smørgrav <des@freebsd.org> 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
>

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=288817